Пакетный менеджер npm начал внедрять проверку пакетов на вредоносный код при публикации — 29 июля 2026 г. в 11:34:48.281
Пакетный менеджер npm начал внедрять проверку пакетов на вредоносный код при публикации Теперь, когда разработчик запускает `npm publish`, новая версия пакета не появляется в реестре сразу. Сначала система анализирует его содержимое на признаки вредоносного кода. По итогам проверки возможны три сценария: * пакет опубликуют в обычном режиме; * отправят на ручную проверку командой Trust & Safety; * заблокируют публикацию. Для проверки система использует комплекс методов: * Распознавание шаблонов в коде. Сканер ищет обфусцированные участки (когда код специально запутывают, чтобы скрыть суть), подозрительные вызовы API (например, обращение к чувствительным системным ресурсам), строки, закодированные в Base64 (это частый способ спрятать вредоносный пейлоад). * Анализ поведения. Система оценивает, что пакет делает: пытается ли подключиться к незнакомым доменам, выполняет ли операции с файловой системой вне ожидаемых сценариев, запускает ли процессы, которые могут указывать на выполнение произвольного кода. * Анализ графа зависимостей. Это помогает выявлять векторы атак через цепочку зависимостей (supply chain attacks) или случаи тайпсквоттинга (когда злоумышленник публикует пакет с именем, очень похожим на название популярной библиотеки, рассчитывая на опечатку разработчика). Команда npm постепенно расширяет покрытие таких проверок и работает над тем, чтобы сократить время анализа. Что важно знать разработчикам: * Задержка. В большинстве случаев проверка занимает около 5 минут, но при высокой нагрузке, большом размере пакета или сложном содержимом ожидание может растянуться до 15 минут и более. Это критично для автоматизированных пайплайнов: сценарии, которые сразу после `npm publish` пытаются установить новую версию, запустить тесты или выполнить другие действия, нужно адаптировать — добавить обработку задержек и повторные попытки. * Если публикацию заблокировали. Сопровождающий может получить уведомление с возможностью подать апелляцию. При серьёзных нарушениях npm также может принять меры в отношении учётных записей сопровождающих. * Инструменты «двойного назначения». Некоторые легитимные пакеты (средства тестирования на проникновение, инструменты исследования безопасности, обфускаторы) используют возможности, которые автоматическая система может принять за вредоносное поведение. Для таких случаев npm ввёл специальную процедуру: сопровождающий должен добавить в `package.json` поле `contentPolicy` со значением `{"class": "dual-use"}` и разместить в корне пакета текстовый файл `DISCLOSURE`. В этом файле нужно описать потенциально опасные возможности инструмента и объяснить, для каких легитимных задач они предназначены. Это поможет команде Trust & Safety отличить специализированный защитный инструмент от зловреда. Однако сама декларация не гарантирует публикацию — пакет всё равно могут дополнительно проверить автоматически или вручную. * Двухфакторная аутентификация. Для пакетов, которые объявили о содержании «двойного назначения», npm вводит обязательную двухфакторную аутентификацию при публикации. Напрямую опубликовать такой пакет можно только из интерактивного сеанса с подтверждением через второй фактор. Если используется доверенная публикация через OIDC (trusted publishing) или токен, позволяющий обходить двухфакторную проверку, потребуется промежуточная стадия (staged publishing), где подтверждение выполняется при переводе подготовленной версии в публичный реестр. * Важное ограничение. Автоматическое сканирование не способно поймать абсолютно весь вредоносный код. Поэтому разработчикам по-прежнему стоит сохранять бдительность: проверять происхождение пакетов, анализировать скрипты установки (например, `postinstall`) и использовать дополнительные инструменты безопасности в своих рабочих процессах. В целом это шаг в сторону повышения безопасности экосистемы JavaScript, но он не отменяет необходимости комплексной защиты на всех этапах разработки и использования зависимостей. https://github.blog/changelog/2026-07-28-npm-publish-time-malwa

