В декабре 2025 года экосистема npm внедрила масштабное обновление системы аутентификации, целью которого стало снижение рисков атак на цепочки поставок программного обеспечения. Триггером для этих решительных действий послужил инцидент с вредоносным ПО Sha1-Hulud, который наглядно продемонстрировал уязвимость существующих механизмов защиты. Хотя пересмотр протоколов безопасности стал значительным шагом вперед, анализ ситуации показывает, что проекты npm по-прежнему не обладают полным иммунитетом к угрозам, а экосистема остается восприимчивой к внедрению вредоносного кода.
Корень проблемы долгое время крылся в использовании так называемых «классических токенов». Эти учетные данные характеризовались длительным сроком действия, широкими полномочиями и бессрочным хранением. Главный недостаток такой архитектуры заключался в том, что при краже токена злоумышленники могли напрямую публиковать вредоносные версии пакетов от имени автора, не требуя при этом наличия публично проверяемого исходного кода. Именно этот механизм эксплуатировался в ходе громких атак, таких как инциденты с Shai-Hulud, Sha1-Hulud и пакетом chalk/debug.
Ответом на эти угрозы стало внедрение интерактивных рабочих процессов и улучшение систем непрерывной интеграции (CI). Теперь разработчики используют краткосрочные сессионные токены, получаемые через команду
Несмотря на эти улучшения, сохраняется критическая уязвимость перед фишингом, нацеленным на обход MFA. Прецедентом служит атака на ChalkJS, где злоумышленники с помощью фишингового письма обманом заставили сопровождающего раскрыть не только логин пользователя, но и одноразовый пароль. Текущая архитектура безопасности не решает эту проблему полностью: даже краткосрочные токены, полученные в результате успешного фишинга, предоставляют злоумышленникам временное окно, достаточное для загрузки вредоносного ПО в репозиторий.
Вторым серьезным пробелом в защите остается опциональный характер MFA при публикации. Разработчики по-прежнему имеют возможность создавать 90-дневные токены с включенной функцией обхода многофакторной аутентификации. По своей сути эти токены идентичны «классическим», что создает опасную лазейку. Доступ к консоли сопровождающего с такими настройками позволяет злоумышленникам публиковать новые вредоносные версии пакетов от имени автора, что фактически сводит на нет усилия по ограничению радиуса поражения таких червей, как Shai-Hulud.
Для устранения этих рисков эксперты предлагают GitHub и npm реализовать трехуровневую стратегию. В долгосрочной перспективе идеальным решением станет повсеместный переход на OIDC, который сложно скомпрометировать. Более реалистичной мерой является принудительное использование MFA для локальной загрузки пакетов, запрещающее создание пользовательских токенов с обходом защиты. Минимально необходимое требование — добавление метаданных к релизам пакетов, что позволит разработчикам идентифицировать и избегать использования продуктов от сопровождающих, пренебрегающих мерами безопасности цепочки поставок.
Альтернативный подход к решению проблемы предлагает компания Chainguard через свой продукт Chainguard Libraries for JavaScript. Их концепция заключается в сборке каждого npm-пакета из проверяемого исходного кода (upstream), вместо загрузки готового артефакта из npm. Анализ публичной базы данных скомпрометированных пакетов показал, что в 98,5% случаев вредоносное ПО отсутствовало в исходном коде и находилось только в опубликованном артефакте. Таким образом, сборка из источника сокращает поверхность атаки примерно на 98,5%. Этот подход соответствует философии «модели швейцарского сыра», где использование библиотек Chainguard в сочетании с мерами npm создает надежную многослойную защиту.
Корень проблемы долгое время крылся в использовании так называемых «классических токенов». Эти учетные данные характеризовались длительным сроком действия, широкими полномочиями и бессрочным хранением. Главный недостаток такой архитектуры заключался в том, что при краже токена злоумышленники могли напрямую публиковать вредоносные версии пакетов от имени автора, не требуя при этом наличия публично проверяемого исходного кода. Именно этот механизм эксплуатировался в ходе громких атак, таких как инциденты с Shai-Hulud, Sha1-Hulud и пакетом chalk/debug.
Ответом на эти угрозы стало внедрение интерактивных рабочих процессов и улучшение систем непрерывной интеграции (CI). Теперь разработчики используют краткосрочные сессионные токены, получаемые через команду
npm login, срок действия которых обычно составляет два часа. Для публикации пакетов по умолчанию активирована многофакторная аутентификация (MFA). В системах CI внедрен механизм OIDC Trusted Publishing, позволяющий получать краткосрочные учетные данные для конкретного запуска, что исключает необходимость хранения секретов в состоянии покоя. Это гарантирует быстрое истечение срока действия прав доступа и требует второго фактора для выполнения чувствительных операций. Несмотря на эти улучшения, сохраняется критическая уязвимость перед фишингом, нацеленным на обход MFA. Прецедентом служит атака на ChalkJS, где злоумышленники с помощью фишингового письма обманом заставили сопровождающего раскрыть не только логин пользователя, но и одноразовый пароль. Текущая архитектура безопасности не решает эту проблему полностью: даже краткосрочные токены, полученные в результате успешного фишинга, предоставляют злоумышленникам временное окно, достаточное для загрузки вредоносного ПО в репозиторий.
Вторым серьезным пробелом в защите остается опциональный характер MFA при публикации. Разработчики по-прежнему имеют возможность создавать 90-дневные токены с включенной функцией обхода многофакторной аутентификации. По своей сути эти токены идентичны «классическим», что создает опасную лазейку. Доступ к консоли сопровождающего с такими настройками позволяет злоумышленникам публиковать новые вредоносные версии пакетов от имени автора, что фактически сводит на нет усилия по ограничению радиуса поражения таких червей, как Shai-Hulud.
Для устранения этих рисков эксперты предлагают GitHub и npm реализовать трехуровневую стратегию. В долгосрочной перспективе идеальным решением станет повсеместный переход на OIDC, который сложно скомпрометировать. Более реалистичной мерой является принудительное использование MFA для локальной загрузки пакетов, запрещающее создание пользовательских токенов с обходом защиты. Минимально необходимое требование — добавление метаданных к релизам пакетов, что позволит разработчикам идентифицировать и избегать использования продуктов от сопровождающих, пренебрегающих мерами безопасности цепочки поставок.
Альтернативный подход к решению проблемы предлагает компания Chainguard через свой продукт Chainguard Libraries for JavaScript. Их концепция заключается в сборке каждого npm-пакета из проверяемого исходного кода (upstream), вместо загрузки готового артефакта из npm. Анализ публичной базы данных скомпрометированных пакетов показал, что в 98,5% случаев вредоносное ПО отсутствовало в исходном коде и находилось только в опубликованном артефакте. Таким образом, сборка из источника сокращает поверхность атаки примерно на 98,5%. Этот подход соответствует философии «модели швейцарского сыра», где использование библиотек Chainguard в сочетании с мерами npm создает надежную многослойную защиту.
