Npm-атаки стали чаще приводить к компрометации CI/CD и облачных секретов

Изменился и характер запросов: компании стали чаще обращаться не после подтвержденной компрометации, а на этапе раннего анализа риска, когда вредоносная версия уже появилась в экосистеме, но еще не успела попасть в продуктивный контур. По данным анализа «Информзащиты», доля таких превентивных запросов выросла с 31% до 54%, а число случаев, где потенциально опасный пакет удавалось изолировать до использования в production-сборке, увеличилось на 38%.

Такая динамика показывает не только рост активности злоумышленников, но и более зрелое отношение бизнеса к open source-рискам. npm остается одной из самых удобных для атакующих экосистем из-за большого числа транзитивных зависимостей, автоматического выполнения lifecycle-скриптов и высокой скорости распространения новых версий. Команда разработки может не устанавливать вредоносный пакет напрямую: он попадает в проект через служебную библиотеку, клиент API, компонент сборки или optional-зависимость. Внешне процесс выглядит штатно, поэтому классические проверки на уровне периметра часто не дают нужного контекста. Защита начинает работать эффективнее там, где контроль зависимостей встроен в пайплайн, а не проводится вручную уже после инцидента.

В 2026 году атаки на npm все чаще нацелены не на конечное приложение, а на среду разработки. Вредоносные пакеты ищут npm-токены, GitHub PAT, SSH-ключи, переменные окружения, cloud credentials, секреты GitHub Actions, GitLab CI, CircleCI, Vercel, Netlify и других платформ. По оценке «Информзащиты», в 61% проанализированных случаев подозрительный пакет пытался получить доступ сразу к нескольким классам секретов. В 34% случаев код содержал признаки самораспространения через публикацию новых версий пакетов от имени скомпрометированного мейнтейнера. В 22% случаев вредоносная активность маскировалась под телеметрию, загрузку runtime-компонентов или стандартные операции сборочного пайплайна. При наличии мониторинга поведения в CI/CD такие сценарии можно выявлять раньше, чем они превращаются в масштабную компрометацию.

Ключевая причина роста таких атак – разрыв между скоростью разработки и глубиной контроля supply chain. Во многих компаниях SBOM формируется ближе к релизу, хотя вредоносный пакет может выполниться еще в тестовой или сборочной среде. Lock-файлы используются не во всех проектах, а npm install по-прежнему встречается в пайплайнах там, где должен применяться npm ci. CI/CD-раннеры нередко имеют избыточный доступ к секретам, а права на сборку, публикацию и работу с облаками объединены в одном контуре. Отдельный риск связан с доверием к формальным признакам легитимности. Подпись пакета и корректный provenance помогают подтвердить происхождение артефакта, но не отвечают на главный вопрос: что делает код при установке, сборке и запуске в CI/CD. Поэтому эти механизмы должны дополнять анализ lifecycle-скриптов, изменений в зависимостях, сетевой активности и доступа к секретам, а не заменять его. Компании, которые совмещают анализ пакетов, контроль секретов и мониторинг поведения сборочной инфраструктуры, сокращают окно риска без остановки разработки.

В отраслевом разрезе наиболее заметная доля обращений пришлась на технологические компании и разработчиков SaaS-решений – 26%. Финансовый сектор занял 19%, в основном из-за развитых внутренних frontend-платформ, SDK и автоматизированных пайплайнов поставки. На ритейл и e-commerce пришлось 16% случаев: риск повышают распределенные веб-команды, подрядчики и большое число клиентских интеграций. Промышленность и энергетика составили 14%, где npm-зависимости чаще встречаются во внутренних порталах, системах мониторинга и сервисах аналитики. Телеком занял 11%, логистика и транспорт – 8%, медиа и образовательные платформы – 6%. Такая картина показывает, что npm-риски перестали быть вопросом только для производителей программного обеспечения. Под удар попадает любой бизнес, где разработка связана с облаками, CI/CD, внешними пакетами и автоматизированной доставкой кода.

Для снижения риска компаниям необходимо выстроить управляемую модель доверия к npm-зависимостям и сборочной инфраструктуре. Новые версии пакетов стоит помещать в карантин на 24-72 часа и пропускать в продуктивные сборки только после проверки изменений в package.json, lifecycle-скриптов, резких скачков размера файлов и появления новых внешних соединений. В CI/CD важно ограничить доступ раннеров к секретам по принципу минимальных привилегий, разделить права на сборку и публикацию, использовать lock-файлы и npm ci вместо npm install, отключать install-скрипты там, где это допустимо, контролировать egress-трафик и направлять загрузку зависимостей через приватный registry или прокси с политиками блокировки. После любого подозрения на компрометацию зависимости требуется ротация npm-токенов, GitHub PAT, SSH-ключей и облачных секретов. Такой подход не останавливает разработку, а переводит open source-компоненты в контролируемый процесс, где риск можно обнаружить до влияния на бизнес-системы.