npm 12 отключает install-скрипты по умолчанию: конец эпохи автозапуска в цепочке поставок

GitHub меняет одно из самых старых и опасных умолчаний в мире JavaScript. В новой мажорной версии пакетного менеджера — npm 12 — команда npm install перестаёт автоматически запускать скрипты установки из зависимостей, а заодно по умолчанию блокирует установку пакетов напрямую из Git-репозиториев и по произвольным URL. Об изменениях предупредили ещё в июньском changelog, а официально о выходе версии объявили 8 июля 2026 года; выкатывание в тег latest идёт в течение месяца. Для экосистемы, которую весь прошлый год сотрясали атаки на цепочку поставок (supply chain — цепочка поставок программного обеспечения), это, пожалуй, самое значимое изменение поведения npm за годы.

Что именно меняется

npm 12 переводит установку пакетов с модели «неявного доверия» на модель «явного доверия»: то, что раньше выполнялось само собой, теперь требует прямого разрешения. Ключевых изменений по умолчанию три.

1. Install-скрипты больше не запускаются автоматически

Раньше при обычном npm install любой пакет в дереве зависимостей мог выполнить свои скрипты жизненного цикла (lifecycle scripts) — preinstall, install и postinstall — прямо на машине разработчика или на сервере сборки. Именно этот механизм годами оставался главным вектором заражения: достаточно было протащить вредоносный код в популярный пакет, и он исполнялся автоматически у всех, кто его ставил.

В npm 12 такие скрипты по умолчанию не выполняются. Чтобы разрешить их для конкретных доверенных пакетов, появились новые команды: npm approve-scripts --allow-scripts-pending покажет список всех зависимостей, которые хотят что-то выполнить при установке, npm approve-scripts вносит выбранные пакеты в белый список (allowlist), а npm deny-scripts — явно запрещает остальные.

2. Git-зависимости — только с флагом --allow-git

npm 12 больше не разрешает зависимости, указывающие на Git-репозитории (ни прямые, ни транзитивные — то есть подтянутые в глубине дерева), пока это не разрешено флагом --allow-git. Причина в тонкой, но опасной лазейке: файл .npmrc внутри Git-зависимости мог подменить путь к исполняемому файлу Git и запустить произвольную команду — даже тогда, когда разработчик считал себя защищённым старым флагом --ignore-scripts.

3. Загрузка по прямым URL — только с флагом --allow-remote

Аналогично блокируются зависимости, скачиваемые с произвольных адресов — например, из HTTPS-архивов (tarball). Теперь для них нужен явный --allow-remote. Это закрывает ещё один способ протащить в сборку код в обход официального реестра.

Почему npm пошла на слом обратной совместимости

Смена умолчаний ломает совместимость — а на такой шаг мейнтейнеры идут только под давлением реальной угрозы. И 2025 год эту угрозу продемонстрировал наглядно.

В сентябре 2025-го через фишинг учётной записи мейнтейнера были захвачены сразу около двух десятков сверхпопулярных пакетов, включая debug и chalk. Совокупно на скомпрометированные библиотеки приходилось порядка 2,6 млрд загрузок в неделю — то есть под удар попала значительная часть всей экосистемы Node.js разом. Чуть позже прокатилась волна самораспространяющегося червя Shai-Hulud, который использовал заражённые пакеты, чтобы красть токены и публиковать новые вредоносные версии от имени жертв. По оценкам исследователей, за один только 2025 год в npm были опубликованы сотни тысяч вредоносных пакетов.

Общая проблема во всех этих историях одна: средний проект тянет за собой десятки транзитивных зависимостей, и любая из них при установке могла молча выполнить код. Отключение автозапуска скриптов бьёт ровно по этому механизму — даже если вредоносный пакет попал в дерево, без явного разрешения он ничего не запустит.

Что это значит для разработчиков и владельцев сайтов

Хорошая новость: для безопасности это большой шаг вперёд. Плохая: часть привычных сборок сломается, и к этому нужно готовиться заранее.

На install-скрипты опираются вполне легитимные пакеты — прежде всего те, что компилируют нативные модули или подтягивают бинарники на этапе установки: node-gyp, sharp, esbuild, puppeteer, prisma и им подобные. После обновления до npm 12 такие зависимости без явного разрешения могут не собраться или не доустановиться. Особенно чувствительны к этому конвейеры сборки (CI/CD): «чистая» установка на сервере, где раньше всё работало само, теперь может упасть, если нужные пакеты не внесены в белый список и не закоммичены в репозиторий.

Практический вывод простой: не стоит ждать, пока обновление прилетит само. Разумнее заранее пройтись по своим проектам, определить, каким пакетам действительно нужен запуск скриптов, и зафиксировать этот список в системе контроля версий — чтобы и локальная разработка, и сборка на сервере вели себя предсказуемо.

Как подготовиться уже сейчас

Готовиться можно, не дожидаясь мажорного релиза. Обновитесь до npm 11.16.0 или новее — эта ветка ещё сохраняет старое поведение, но уже показывает предупреждения о том, что именно сломается в 12-й версии. Затем выполните npm approve-scripts --allow-scripts-pending, чтобы увидеть полный список зависимостей, претендующих на запуск скриптов, и осознанно решить по каждой: доверяете — в белый список, нет — под запрет.

Важно не поддаться соблазну выдать «разрешение всем сразу»: массовый allowlist ради того, чтобы «просто заработало», обнуляет весь смысл нововведения. Утверждайте только конкретные пакеты в проверенных версиях и обязательно коммитьте обновлённую конфигурацию, чтобы она применялась и в CI. Для Git- и URL-зависимостей, если они вам действительно нужны, используйте флаги --allow-git и --allow-remote точечно.

Более широкий контекст: доверенная публикация

Отключение скриптов — не разовая мера, а часть большой перестройки безопасности npm, которую GitHub ведёт с конца 2025 года. Ей предшествовали отзыв старых «классических» токенов, обязательная двухфакторная аутентификация с аппаратными ключами для публикации и переход на короткоживущие сессии вместо вечных учётных данных. Отдельно появилась доверенная публикация (OIDC Trusted Publishing) — механизм, который позволяет публиковать пакеты из конвейеров CI/CD вообще без хранимых токенов, опираясь на криптографическое подтверждение источника сборки.

График закручивания гаек известен и дальше. Уже в начале августа 2026 года гранулярные токены доступа (GAT), настроенные в обход 2FA, потеряют право на чувствительные операции с аккаунтом и пакетами. А с января 2027-го прямая публикация такими токенами станет невозможной вовсе: выкладка перейдёт на staged-релизы, требующие подтверждения человеком через двухфакторную аутентификацию. Логика единая — убрать из процесса всё, что может сработать «само по себе» без явного согласия ответственного человека.

Что дальше

npm 12 закрепляет разворот всей индустрии к принципу «явного доверия» в цепочке поставок: инструмент по умолчанию делает безопасное, а удобное-но-рискованное поведение приходится включать осознанно. Для разработчиков это означает несколько часов работы на аудит зависимостей и настройку CI сейчас — в обмен на то, что один случайно затянутый вредоносный пакет больше не сможет молча выполнить код на их машинах и серверах. Тем, кто держит сайты и сервисы на Node.js, стоит проверить свои сборки заранее: обновление уже выкатывается, и лучше встретить его подготовленными, чем ловить упавший деплой.