Трижды за восемь месяцев срабатывала одна и та же схема защиты от npm-червей. Разные злоумышленники, разные пакеты, один и тот же механизм и один и тот же временной промежуток между публикацией и обнаружением, что делало каждый случай возможным. Если вы спрашиваете, что такое npm-червь на самом деле и почему эта схема повторяется вместо того, чтобы быть исправленной, вот честный ответ: инциденты, механизмы и единственная уязвимость, которую оставляет даже надежная система защиты.
Что такое червь npm?
npm-червь — это фрагмент вредоносного кода, опубликованный в реестре npm, который автоматически распространяется на другие пакеты после запуска, обычно путем кражи учетных данных разработчика и использования их для внедрения той же полезной нагрузки во все пакеты, контролируемые этим разработчиком. Это «червь» в классическом смысле: он не ждет, пока кто-то установит его намеренно, он распространяется самостоятельно, от пакета к пакету, от учетной записи к учетной записи, со скоростью машины.
Именно это самораспространение отличает инцидент с npm-червем от обычного вредоносного пакета. Один вредоносный пакет — это иголка в стоге сена. npm-червь превращает каждый скомпрометированный разработчик в новую точку распространения, и стог сена начинает генерировать свои собственные иголки.
Крупнейшие на сегодняшний день инциденты с червями npm
В прошлом году мы провели три реальных тестовых запуска шаблона npm worm, и каждый последующий был эффективнее предыдущего:
- Шай-Хулуд (сентябрь 2025 г.). Первый задокументированный самораспространяющийся червь npm. Он скомпрометировал учетные данные сопровождающих проекта, а затем использовал их для публикации вредоносных версий каждого пакета, находящегося под контролем этого сопровождающего, превращая самих разработчиков в механизм распространения следующего этапа червя.
- axios (март 2026 г.). Вредоносное ПО государственного уровня, скрытое внутри пакета, загружаемого примерно 100 миллионов раз в неделю. Это не червь в строгом смысле слова, но доказательство того, что та же модель доверия в экосистеме npm, которую использовал Шай-Хулуд, может распространять вредоносный код в действительно огромных масштабах.
- SAP npm (апрель 2026 г.). В то время это описывалось как мини-версия «Шай-Хулуда»: тот же самый узор в виде червя, повторенный в большем масштабе, менее чем через год после первоначального инцидента. Механизм не изменился. Защитные механизмы тоже в основном остались прежними.
Три случая заражения червем npm. один повторяющийся узор: скомпрометировать доверенного издателя, использовать его учетные данные для автоматического распространения и рассчитывать на то, что разрыв между публикацией и обнаружением сообществом сделает все остальное.
Повторяющийся узор
Если отбросить все детали, то каждый случай появления червя npm следует одним и тем же четырем сценариям:
- Взлом аккаунта. Токен для публикации контента разработчиками, npm loginили же учетные данные CI украдены, обычно в результате фишинга, утечки секрета или компрометации зависимостей на более высоком уровне их собственной цепочки.
- Бесшумная инъекция. Злоумышленник распространяет новую версию легитимного, доверенного пакета с добавлением вредоносного кода, часто внутри скрипта postinstall или другого скрипта жизненного цикла, который запускается автоматически в момент установки.
- Автоматическое распространение. Если скомпрометированный разработчик контролирует другие пакеты или если вредоносный скрипт сам собирает дополнительные учетные данные, червь распространяется на следующий пакет и следующего разработчика без дальнейших действий со стороны злоумышленника.
- Задержка обнаружения. Пакет находится в реестре и доступен для установки любому пользователю, пока кто-нибудь его не заметит, не сообщит о проблеме, после чего его удалят. Эта задержка, несколько часов в одних случаях, несколько дней в других, — это всё то время, которое необходимо червю.
Для защиты действительно важно распознать этот четвертый этап. Каждая стратегия противодействия инциденту с червем npm по своей сути является попыткой сократить или обойти этот период задержки обнаружения.
Достойная упоминания структура: решение проблемы задержки отклика в SIP.
Не все отклики на эту схему поступают от поставщиков. Один из самых очевидных примеров — SIP, План обеспечения безопасности Мохаммеда-Али Араби.Это пятиступенчатая система мер по управлению рисками в цепочке поставок программного обеспечения, разработанная на основе очень практичного вопроса, заданного в конце сессии SafeDev: «Если мы можем сделать только несколько вещей, что нам следует сделать в первую очередь?»
Вторая мера контроля SIP направлена непосредственно на проблему червя npm: замораживание непроверенных зависимостей с пятидневным периодом ожидания и отключение скриптов жизненного цикла, чтобы вредоносный postinstall не мог автоматически выполняться во время установки. На практике это означает следующее: min-release-age=5 и ignore-scripts=true в проекте .npmrcЭто правило внедрено в CI, чтобы файл блокировки не мог незаметно разрешить пакет, опубликованный вчера. Это действительно надежный и не требующий больших усилий механизм контроля, который напрямую решает ту же проблему задержки обнаружения, от которой зависит каждый инцидент с червем npm. Подробнее:
Где окно перезарядки все еще оставляет пробел
Период ожидания — это своего рода пари: сообщество заметит и сообщит о вредоносном пакете до истечения этого периода. В большинстве случаев это пари оправдывается. Значительная часть скомпрометированных пакетов обнаруживается в течение первых нескольких дней после публикации, именно поэтому пятидневный период является разумным вариантом по умолчанию.
But an npm worm doesn’t behave like a typical malicious package, and that changes what a fixed cooldown can and can’t do for you.
To be precise about speed: a fast-propagating worm doesn’t actually defeat the cooldown itself. If you enforce a strict minimum release age, packages published during that initial wave are still too new to enter a build, no matter how many packages the worm compromises in the meantime. Speed matters, but it matters for everyone downstream who isn’t running a cooldown, not for beating one that’s already enforced.
The real limitation is patience. A more careful payload can sit dormant past the cooldown period, activating only once the days have cleared and the package has aged into the “trusted” zone, precisely because it knows a cooldown is watching. That’s the scenario where a fixed cooldown alone isn’t enough, and exactly where something like MEW’s evidence-based detection needs to sit alongside it, not instead of it.
Ни один из этих сбоев не является недостатком в концепции SIP. Период ожидания — это ставка на обнаружение активности сообщества, а у обнаружения активности сообщества есть нижний предел: оно не может выявить то, о чем еще никто не сообщил. Это не уникальная проблема SIP, это структурное ограничение любой системы защиты, которая ждет появления подписи, уведомления или публичного сообщения, прежде чем действовать.
Как MEW сокращает разрыв между временем охлаждения и окном охлаждения
Это предварительноcisЭли зе гл Система раннего оповещения о вредоносном ПО (MEW) от Xygeni MEW создан для закрытия угроз. Вместо того чтобы ждать сообщений от сообщества или опубликованной подписи, MEW непрерывно сканирует NPM, PyPI и Maven по мере публикации новых пакетов и версий, анализируя поведение, а не сопоставляя его с известными угрозами. Если что-то выглядит вредоносным, оно помещается в карантин, и обнаружение подтверждается исследователями безопасности до публичного раскрытия, а не после.
Это различие важно для обоих описанных выше режимов отказа npm-червей. Против быстро распространяющегося червя предварительное обнаружение сигнатур не требует пяти дней, которые предполагает период ожидания. Против пассивного, спящего вредоносного кода поведенческий анализ MEW не ищет возраст или репутацию, а ищет, что на самом деле делает код, поэтому ожидание окончания периода ожидания ничего не даст злоумышленнику.
Межсетевой экран зависимостей MEW расширяет эту функцию до самого момента установки, блокируя вредоносный пакет в режиме реального времени, даже если он прошел предыдущие проверки, и тот же уровень обнаружения охватывает и другие аспекты. CI/CD Одна из сторон инцидента с npm-червем: шаблон unlock-branch, inject, relock, позволяющий злоумышленнику распространять вредоносный код. commit и незаметно заметать следы, обеспечивая при этом полный контрольный след, если это все-таки произойдет.
SIP и MEW отвечают на один и тот же вопрос, но на разных уровнях.
Всё это, конечно, не делает управление временем ожидания в SIP неправильным, и стоит прямо сказать: пятидневное время ожидания с отключенными скриптами жизненного цикла по-прежнему является одним из самых быстрых и дешевых способов защиты от обычного инцидента с npm-червями, и оно должно быть частью любого серьезного плана по усилению безопасности цепочки поставок. Однако, по своей сути, оно не способно обнаружить то, что сообщество еще не обнаружило. Это задача для непрерывного обнаружения на основе поведения, работающего под действием времени ожидания, а не вместо него.
При совместном применении эти два подхода решают одну и ту же проблему: SIP повышает безопасность сборки. pipelineЗаморозка зависимостей и образ контейнера, созданный на основе известной и раскрытой картины угроз, в то время как предварительное обнаружение сигнатур MEW охватывает инциденты с червями npm, которые еще не были раскрыты, те, которые окно задержки, по своей собственной логике, не может предвидеть.
FAQ
Что такое npm-червь, если говорить одним предложением?
Вредоносный код, опубликованный в npm, автоматически распространяется на другие пакеты, как правило, путем кражи учетных данных разработчика и использования их для внедрения той же вредоносной программы в другие места без каких-либо дальнейших действий со стороны злоумышленника.
Каждый ли вредоносный npm-пакет — это npm-червь?
Нет. Вредоносный пакет, который не распространяется самостоятельно, — это атака на цепочку поставок, но не червь. Отличительной чертой инцидента с npm-червем является этап самораспространения: одно нарушение безопасности автоматически приводит к следующему.
Остановит ли период ожидания зависимостей распространение червя npm?
Это значительно снижает риск, поскольку о большинстве вредоносных пакетов сообщается в течение первых нескольких дней после публикации. Но период ожидания — это ставка на скорость обнаружения сообществом, и быстро распространяющийся или намеренно спящий npm-червь может быть создан специально для того, чтобы опередить этот период.
Что именно позволяет обнаружить червя npm до истечения периода ожидания?
Непрерывное сканирование на основе анализа поведения, не зависящее от наличия подписи или публичного отчета. Именно этот пробел призваны заполнить инструменты обнаружения до появления подписи, такие как MEW от Xygeni.
