Масштабный всплеск атак на экосистему npm за последний год выявил резкий сдвиг в ландшафте угроз, связанных с цепочками поставок программного обеспечения.
То, что ранее сводилось к неуклюжим попыткам тайпосквоттинга, трансформировалось в скоординированные вторжения, основанные на компрометации учётных данных и нацеленные на разработчиков, конвейеры CI и доверенную автоматизацию, лежащую в основе современной разработки.
Для руководителей служб безопасности это больше не нишевые ошибки разработчиков — это прямой путь к производственным системам, облачной инфраструктуре и миллионам конечных приложений.
Цель теперь состоит не в том, чтобы обмануть отдельного разработчика, а в том, чтобы незаметно перехватить его полномочия. А вместе с ними — и его охват дистрибуции.
«NPM является привлекательной мишенью, поскольку это крупнейшее в мире хранилище JavaScript-пакетов и ключевая точка контроля для распространения ПО», — заявила Мелинда Маркс, директор практики кибербезопасности в Enterprise Security Group. «Командам по безопасности необходимо понимать зависимости, а также находить способы регулярного аудита и смягчения рисков».
Структурные уязвимости в инфраструктуре npm
Практически каждое предприятие в той или иной степени полагается на npm. По данным IDC, 93% организаций используют программное обеспечение с открытым исходным кодом, а npm остаётся крупнейшим реестром пакетов в экосистеме JavaScript. «Компрометация одного популярного пакета может немедленно затронуть миллионы конечных пользователей и приложений», — отметила менеджер по исследованиям IDC (DevSecOps) Кэти Нортон, превращая одну украденную учётную запись в то, что она назвала «мастер-ключом» для дистрибуции.
Однако этот масштаб — лишь часть риска.
Уязвимость усиливается структурными недостатками в методах защиты современных конвейеров разработки, заметила Нортон. «Отдельные сопровождающие открытого исходного кода часто не имеют тех ресурсов безопасности, на которые полагаются корпоративные команды, что делает их уязвимыми для социальной инженерии», — сказала она. «Бегунки CI/CD и машины разработчиков регулярно обрабатывают долгоживущие секреты, которые хранятся в переменных окружения или конфигурационных файлах и легко извлекаются вредоносным ПО».
«Кроме того, сборочные системы, как правило, отдают приоритет скорости и надёжности над видимостью безопасности, что приводит к ограниченному мониторингу и длительному пребыванию злоумышленников в системе после первоначального доступа», — добавила Нортон.
Хотя руководители служб безопасности не смогут решить эту проблему исключительно патчами, они могут снизить уровень угрозы. Эксперты постоянно указывают на одни и те же приоритеты: рассматривать бегунки CI как производственные активы, агрессивно ротировать и ограничивать область действия токенов публикации, отключать скрипты жизненного цикла, если они не требуются, и закреплять зависимости на неизменяемых версиях.
«Эти атаки на npm нацелены на фазу предварительной установки зависимостей ПО, поэтому типичные методы безопасности цепочки поставок, такие как сканирование кода, не могут противостоять таким вторжениям», — пояснила Маркс. Обнаружение требует анализа в реальном времени и выявления аномалий, а не использования инструментов, основанных на сигнатурах.
От ловушек опечаток к легитимным бэкдорам
Годами модель угроз npm определялась тайпосквоттингом. Злоумышленники публиковали пакеты с названиями, лишь немного отличающимися от популярных библиотек, например, «lodsash», «expres», «reacts», и ждали, пока автоматизация или человеческая ошибка сделают своё дело. Воздействие, как правило, было ограниченным, а устранение последствий — простым.
Эта модель начала давать сбой в 2025 году.
Вместо того чтобы маскироваться под популярные пакеты, злоумышленники всё чаще компрометировали реальные. Фишинговые кампании, выдававшие себя за npm, похищали учётные данные сопровождающих. Затем украденные токены использовались для публикации вредоносных обновлений, которые выглядели легитимными для всех конечных потребителей. Кампания Shai-Hulud продемонстрировала масштаб проблемы, затронув десятки тысяч репозиториев и используя скомпрометированные учётные данные для самораспространения по всей экосистеме.
«Экосистема npm стала главной драгоценностью современной разработки», — отметил Куш Пандья, исследователь кибербезопасности из Socket.dev. «Когда компрометируется один плодовитый сопровождающий, радиус поражения охватывает сотни последующих проектов».
Результатом стал тихий, но мощный сдвиг: злоумышленникам больше не нужно было создавать убедительные подделки. Они могли доставлять вредоносное ПО через доверенные каналы, подписанные и с версионированием, как любое штатное обновление.
Среды разработки важнее ноутбуков разработчиков
Современные атаки на npm всё чаще активируются внутри сред CI/CD, а не на ноутбуках разработчиков. Скрипты после установки (post-install scripts), долгое время считавшиеся безвредными вспомогательными средствами настройки, стали вектором исполнения, способным автоматически запускаться внутри GitHub Actions или GitLab CI. Попав в среду исполнения, вредоносные пакеты могли считывать переменные окружения, похищать токены публикации, подменять артефакты сборки или даже публиковать дополнительные вредоносные релизы под именем жертвы.
«Среды разработки и бегунки CI теперь ценнее конечных машин пользователей», — отметил Пандья. «Они, как правило, обладают более широкими разрешениями, доступом к секретам и возможностью отправлять код в продакшн».
Несколько кампаний, замеченных в середине 2025 года, были явно осведомлены о CI, активируясь только при обнаружении автоматизированных сборочных сред. Некоторые включали задержку исполнения или самоисчезающие полезные нагрузки, что минимизировало возможности для криминалистического анализа, одновременно максимизируя кражу учётных данных.
Для предприятий это означает фундаментальный сдвиг риска. Системы CI часто работают с более высокими привилегиями, чем любой отдельный пользователь, но при этом мониторятся гораздо менее строго. «Они часто защищены слабыми настройками по умолчанию: долгоживущими токенами публикации, избыточно разрешительными секретами CI, неявным доверием к скриптам жизненного цикла и метаданным пакетов, а также слабой изоляцией между сборками», — подчеркнул Пандья.
По данным IDC Research, организации выделяют лишь около 14% бюджетов AppSec на безопасность цепочек поставок, при этом только 12% из них считают безопасность конвейера CI/CD главным риском.
Обход защиты как функция первого класса
По мере того как защитники совершенствовали методы обнаружения подозрительных пакетов, злоумышленники тоже адаптировались.
Недавние кампании в npm использовали невидимые символы Unicode для маскировки зависимостей, многоступенчатые загрузчики, которые извлекают реальные полезные нагрузки только после проверки окружения, и ссылки командно-контрольных центров (C2), размещённые в блокчейне, чтобы избежать блокировки. Другие разворачивали червеподобное поведение, используя украденные учётные данные для массовой публикации дополнительных вредоносных пакетов.
Ручной просмотр стал практически неэффективным против такого уровня методов. «Дни, когда можно было просмотреть index.js и заметить вредоносный eval(), прошли», — сказал Пандья.
«Современные пакеты скрывают вредоносную логику за слоями кодирования, отложенного выполнения и отпечатков окружения». Нортон поддержала эту озабоченность, отметив, что эти атаки происходят на поведенческом уровне, где статическое сканирование оказывается недостаточным. «Техники обфускации затрудняют отличие вредоносной логики от законной сложности в крупных JavaScript-проектах», — заявила она. «Полезные нагрузки, осведомлённые о CI, и скрипты после установки вносят поведение, которое проявляется только при определённых условиях окружения».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Shweta Sharma
