GitHub раскатил для npm новые меры против атак на цепочку поставок. Главная новинка — staged publishing: пакет не становится доступным сразу, а проходит ручное подтверждение через 2FA, только после этого его можно установить.

Зачем npm ужесточил публикации

Атаки на open-source экосистемы бьют не по одной компании, а по тысячам проектов сразу. Злоумышленникам достаточно подменить популярный пакет или внедрить вредоносный код в зависимость, и заражение быстро расходится по чужим сборкам, CI/CD и рабочим станциям разработчиков.

Именно поэтому npm стал двигаться к схеме, где у публикации есть явный человеческий контроль. Это не убирает риск полностью, но сильно усложняет массовую подмену пакетов через скомпрометированные учётки или автоматические пайплайны.

Схожую логику уже обсуждали в разборе атаки на Laravel-Lang: когда ломают не сервер, а зависимость, ущерб распространяется дальше одного проекта.

Что изменилось в npm

Первая мера — staged publishing. Разработчик отправляет tarball в очередь, а не выпускает пакет напрямую. Потом мейнтейнер вручную подтверждает публикацию, проходя 2FA-проверку, и только после этого версия становится доступной для установки.

GitHub подчёркивает, что так появляется «proof of presence» — подтверждение, что публикацию совершил живой человек, а не только автоматизированный процесс. Это важно и для CI/CD, и для trusted publishing через OpenID Connect.

Есть и ограничения. Новый режим работает только для пакетов, которые уже существуют в реестре npm. Для совсем новых пакетов staged publishing пока не подходит, а у аккаунта должен быть включён второй фактор.

Вторая часть обновления — новые флаги для установки из не-реестровых источников:

  • --allow-file — для локальных путей и tarball-файлов;
  • --allow-remote — для удалённых URL, включая https-tarball;
  • --allow-directory — для локальных директорий.

Идея простая: разработчик сам задаёт явный список разрешённых источников, а не пускает в проект всё подряд.

Какие есть плюсы и минусы

staged publishing лучше всего защищает от случайных и компрометированных публикаций. Его плюс — ручное подтверждение перед выпуском; минус — лишний шаг в процессе и зависимость от 2FA.

Trusted publishing через OIDC хорошо снимает часть боли с секретами и паролями в CI/CD. Но этот механизм всё равно не заменяет внимательную проверку релиза человеком.

Новые install-флаги полезны там, где команды тянут зависимости не только из реестра, но и из локальных архивов, директорий или внешних ссылок. Плюс — больше контроля. Минус — выше шанс сломать старые сборки, если проект привык к нестрогим правилам.

Для понимания общей картины полезно посмотреть и на утечку секретов в CISA: история снова показывает, что слабое место часто не в коде, а в учётках, токенах и доверии к автоматике.

Кому что подходит

Если вы мейнтейните популярный пакет, staged publishing стоит включить первым делом. Это особенно актуально для библиотек, которые тянут десятки или сотни других проектов.

Если у вас команда с развитым CI/CD, разумнее сочетать OIDC-публикацию с ручным подтверждением релиза и жёсткими правилами установки. Такой подход снижает шанс, что компрометация одного контура сразу приведёт к заражению всего репозитория.

Если вы обычный разработчик, который редко публикует пакеты, но часто собирает проект из чужих зависимостей, важнее всего дисциплина: обновлённый npm CLI, проверка источников установки и второй фактор на учётке.

Что делать прямо сейчас

Если вы работаете с npm, план действий довольно приземлённый. Слой защиты для рабочих устройств стоит рассматривать как один из элементов общей цифровой гигиены — вместе с менеджером паролей и 2FA.

  • Проверьте, включён ли у вас второй фактор для npm-аккаунта.
  • Обновите npm CLI до версии 11.15.0 или новее.
  • Оцените, подходит ли вашим пакетам staged publishing.
  • Проверьте, не тянет ли проект зависимости из нестандартных источников.
  • Для CI/CD уберите лишние секреты и переведите публикации на trusted publishing через OIDC.
  • Ограничьте установку пакетов только теми источниками, которым вы действительно доверяете.
  • Пересмотрите внутренние правила ревью релизов, если пакет важен для компании.
Поделиться: