Злоумышленники все чаще используют npm-пакеты не для атаки на само приложение, а для доступа к среде разработки. Под удар попадают токены, GitHub Actions, облачные ключи и права на публикацию новых версий.
Компании стали чаще проверять npm-зависимости до того, как подозрительный пакет попадает в продуктивную сборку. По данным «Информзащиты», в январе–мае 2026 года число обращений по проверке npm-зависимостей и расследованию подозрительной активности в цепочках поставки ПО выросло на 42% по сравнению с тем же периодом 2025 года.
Изменился и характер запросов. Если раньше компании чаще обращались уже после подтвержденной компрометации, то теперь заметно чаще приходят на этапе раннего анализа риска. В экосистеме уже появилась вредоносная версия пакета, но она еще не успела дойти до production. Доля таких превентивных обращений выросла с 31% до 54%. Число случаев, когда потенциально опасный пакет удавалось изолировать до использования в продуктивной сборке, увеличилось на 38%.
Эта динамика совпадает с тем, что фиксируют международные исследователи. В конце мая Microsoft описала кампанию из 14 typosquatting-пакетов в npm, которые маскировались под библиотеки для OpenSearch, ElasticSearch, DevOps и настройки окружений. После установки такие пакеты искали AWS credentials, HashiCorp Vault tokens, секреты CI/CD и npm publish tokens. То есть атака была нацелена не столько на клиентское приложение, сколько на инфраструктуру, через которую это приложение собирается, публикуется и получает доступ к облакам.
Пакет уже не просто зависимость
npm остается удобной средой для атак по той же причине, по которой он удобен для разработки. В проектах много транзитивных зависимостей, новые версии быстро расходятся по цепочкам, а lifecycle-скрипты могут выполняться автоматически при установке пакета. Команда может не добавлять вредоносную библиотеку напрямую. Она попадает в проект через служебный компонент, SDK, клиент API, инструмент сборки или optional-зависимость.
Снаружи это выглядит как обычное обновление. Разработчик запускает привычную команду, CI получает привычный набор шагов, пакет может быть опубликован из легитимного аккаунта и иметь корректные формальные признаки происхождения. Проблема становится заметной позже, когда токен уже использован для доступа к репозиторию, облаку или публикации следующей зараженной версии.
В 2026 году атаки на npm все чаще нацелены именно на среду разработки. Вредоносные пакеты ищут npm-токены, GitHub PAT, SSH-ключи, переменные окружения, cloud credentials, секреты GitHub Actions, GitLab CI, CircleCI, Vercel, Netlify и других платформ. По оценке «Информзащиты», в 61% проанализированных случаев подозрительный пакет пытался получить доступ сразу к нескольким классам секретов. В 34% случаев код содержал признаки самораспространения через публикацию новых версий пакетов от имени скомпрометированного мейнтейнера. В 22% случаев вредоносная активность маскировалась под телеметрию, загрузку runtime-компонентов или стандартные операции сборочного пайплайна.
Похожую картину описывает Unit 42. После крупной кампании Shai-Hulud в 2025 году атаки на npm стали не разовыми историями про typosquatting, а более сложными сценариями с самораспространением, кражей токенов и закреплением в CI/CD. По данным Unit 42, в июне 2026 года была скомпрометирована группа пакетов в namespace @redhat-cloud-services, а злоумышленники использовали доверие к GitHub Actions и SLSA provenance. Формально артефакты могли выглядеть корректно, потому что действительно были собраны через доверенный пайплайн. Проблема была в том, что в этот пайплайн уже попал вредоносный код.
Когда CI становится новой точкой входа
CI/CD долго воспринимался как технический слой между разработкой и эксплуатацией. Но теперь это уже не просто автоматизация сборки. В пайплайнах живут секреты, права на публикацию, доступы к контейнерным реестрам, облакам, внутренним пакетам и инфраструктуре. Если злоумышленник попадает в этот контур, он получает не одно приложение, а рычаг для движения дальше.
В марте GitHub прямо назвал CI/CD частью критической инфраструктуры для компаний и open source. В дорожной карте GitHub Actions на 2026 год компания пишет, что атаки все чаще нацелены на автоматизацию CI/CD, а проблемы с dependency management, неявными границами доверия, управлением секретами и наблюдаемостью приводят к росту атак на цепочки поставки ПО. Среди ответных мер GitHub выделяет более точное разграничение секретов, политики доступа, наблюдаемость для раннеров и контроль исходящего трафика.
Это важный сдвиг для корпоративной ИБ. Проверить имя пакета и наличие подписи уже недостаточно. Подпись и provenance помогают понять, откуда пришел артефакт, но не отвечают на другой вопрос: что делает код при установке, сборке и запуске в CI/CD. Именно там вредоносный пакет может искать токены, открывать внешние соединения, читать переменные окружения и пробовать публиковать новые версии от имени легитимного владельца.
Британский NCSC в июньских рекомендациях также обращает внимание на злоупотребление автоматизацией. Современная разработка полагается на внешние зависимости и CI/CD, а установка пакетов и выполнение скриптов часто происходят без ручного участия. В такой модели один вредоносный компонент может быстро пройти по цепочке зависимостей и оказаться в разных средах.
Свежие инциденты показывают механику
Один из недавних примеров — компрометация пакетов @redhat-cloud-services. Red Hat подтвердила, что 1 июня 2026 года была публично раскрыта supply chain-компрометация нескольких npm-пакетов в этом namespace. По предварительным данным компании, скомпрометированный GitHub-аккаунт использовался для внедрения вредоносного кода в пакеты, поддерживаемые в GitHub-организации Red Hat. При этом Red Hat отдельно уточнила, что затронутые пакеты относились к frontend-библиотекам для Hybrid Cloud Console, а релиз самой консоли в период компрометации не публиковался.
Технический разбор StepSecurity показывает, почему такие атаки опасны именно для сборочной среды. Вредоносный payload запускался через preinstall-hook при каждом npm install, то есть до выполнения кода приложения. Он искал секреты GitHub Actions, AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm и CircleCI. По данным StepSecurity, код также обладал признаками самораспространяющегося червя и мог использовать украденные npm-токены для публикации зараженных версий других пакетов.
Еще один показательный пример — атака на экосистему AntV. Microsoft писала, что злоумышленник скомпрометировал аккаунт мейнтейнера @antv и опубликовал вредоносные версии популярных пакетов для визуализации данных. Через цепочки зависимостей компрометация затронула и другие библиотеки, включая echarts-for-react, у которой более 1 млн загрузок в неделю. Payload запускался при npm install и был ориентирован на кражу учетных данных из GitHub Actions и других сред.
В мае похожий риск дошел до крупных технологических компаний. OpenAI сообщила, что атака на TanStack npm в рамках Mini Shai-Hulud затронула два корпоративных устройства сотрудников. По заявлению компании, пользовательские данные, production-системы, интеллектуальная собственность и ПО не были скомпрометированы, однако OpenAI зафиксировала активность, связанную с доступом к ограниченной части внутренних репозиториев и credential-focused exfiltration. В ответ компания изолировала затронутые системы, отозвала сессии, ротировала учетные данные и временно ограничила workflow для развертывания кода.
Почему бизнес замечает проблему раньше
Рост превентивных обращений показывает, что компании начинают смотреть на open source не только как на набор библиотек, но и как на часть производственного контура. Это особенно важно для организаций, где разработка связана с облаками, микросервисами, внутренними платформами, клиентскими SDK и автоматизированной доставкой кода.
По данным «Информзащиты», чаще всего с такими запросами обращались технологические компании и разработчики SaaS-решений. На них пришлось 26% случаев. Финансовый сектор занял 19%, ритейл и e-commerce — 16%, промышленность и энергетика — 14%, телеком — 11%, логистика и транспорт — 8%, медиа и образовательные платформы — 6%.
Такая картина показывает, что npm-риски давно вышли за пределы производителей программного обеспечения. У банка могут быть внутренние frontend-платформы и SDK. У ритейлера — распределенные веб-команды, подрядчики и множество клиентских интеграций. У промышленной компании — порталы, системы мониторинга и сервисы аналитики. Везде, где есть npm-зависимости, CI/CD и облачные секреты, появляется похожая поверхность атаки.
Главная причина роста таких атак — разрыв между скоростью разработки и глубиной контроля supply chain. Во многих компаниях SBOM формируется ближе к релизу, хотя вредоносный пакет может выполниться раньше, еще в тестовой или сборочной среде. Lock-файлы используются не во всех проектах, а npm install по-прежнему встречается в пайплайнах там, где безопаснее применять npm ci. CI/CD-раннеры нередко получают избыточный доступ к секретам, а права на сборку, публикацию и работу с облаками оказываются объединены в одном контуре.
По словам Анатолия Песковского, директора департамента наступательной безопасности компании «Информзащита», npm-атаки опасны именно тем, что долго не выглядят как инцидент. Разработчик устанавливает обычную зависимость, CI выполняет привычные команды, а пакет может быть опубликован из легитимного аккаунта и даже иметь формальные признаки доверия. Но если в этот момент вредоносный код уже получил токен, проблема проявится позже — например, через доступ к репозиторию или публикацию новой зараженной версии. Во второй половине 2026 года в «Информзащите» ожидают больше комбинированных сценариев: компрометации мейнтейнеров, отравления CI/CD-кеша и злоупотребления доверенными publisher-механизмами. Поэтому проверка только имени пакета и наличия подписи уже не дает достаточной защиты.
Что меняется в защите
Защита от таких атак начинается не с запрета open source, а с управления доверием. Новые версии пакетов стоит помещать в карантин на 24–72 часа и пропускать в продуктивные сборки только после проверки изменений в package.json, lifecycle-скриптов, резких скачков размера файлов и появления новых внешних соединений.
В CI/CD важно ограничивать доступ раннеров к секретам по принципу минимальных привилегий, разделять права на сборку и публикацию, использовать lock-файлы и npm ci вместо npm install, отключать install-скрипты там, где это возможно, контролировать egress-трафик и направлять загрузку зависимостей через приватный registry или прокси с политиками блокировки.
После любого подозрения на компрометацию зависимости требуется ротация npm-токенов, GitHub PAT, SSH-ключей и облачных секретов. Причем речь должна идти не только о production, но и о средах разработки, тестирования и сборки. Именно там вредоносный пакет может выполниться первым.
npm-атаки больше не выглядят как история про одну неудачную библиотеку. Это проверка того, насколько компания понимает собственную цепочку поставки ПО. Кто может публиковать пакет. Какие секреты доступны раннеру. Куда может сходить сборочная среда. Какие зависимости обновляются автоматически. И кто заметит странное поведение до того, как обычная установка пакета превратится в доступ к облаку или репозиторию.