npm Install Scripts Opt-In RFC:
Конец самой опасной настройки npm по умолчанию

Что предлагает RFC

15 мая 2026 года инженер GitHub Джейми Маги (Jamie Magee) опубликовал RFC, предлагающий фундаментальное изменение в том, как npm обрабатывает скрипты установки (preinstall, install, postinstall, prepare). Суть проста: вместо автоматического выполнения скриптов зависимостей, npm должен требовать явного согласия разработчика.

RFC был опубликован в JavaScript Weekly Issue 786 (19 мая 2026) и Node Weekly Issue 625 (21 мая 2026), где его назвали давно назревшим улучшением безопасности для экосистемы npm. Предложение напрямую решает проблему, которая делает npm аутсайдером: это единственный крупный менеджер пакетов, запускающий скрипты зависимостей по умолчанию.

Согласно предложению, при запуске npm install <package>, если у пакета есть скрипты установки, npm будет либо:

• Запрашивать подтверждение разработчика (для каждого пакета или сессии), или
• Пропускать скрипты, если пакет не указан в конфигурации allowedScripts, или
• Требовать явный флаг --allow-scripts для их выполнения

Точный UX-механизм ещё обсуждается, но направление ясно: нулевое доверие по умолчанию для скриптов установки.

Почему это важно: поверхность атаки скриптов установки

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

Пример Mini Shai-Hulud

Червь Mini Shai-Hulud (апрель–май 2026) скомпрометировал более 170 npm-пакетов в экосистемах TanStack, Mistral AI, UiPath и других, внедряя код для кражи учётных данных через хуки preinstall. Атака сработала потому, что npm запускал эти скрипты автоматически — без подтверждения пользователя, предупреждения или аудита.

Вредоносное ПО использовало хук preinstall для загрузки и выполнения нагрузки на базе Bun, которая похищала токены GitHub, учётные данные npm, облачные ключи и секреты CI/CD. Затем украденные данные использовались для публикации скомпрометированных версий других пакетов, создавая червеобразную цепочку распространения. Весь вектор атаки зависел от поведения npm по умолчанию — запускать скрипты без вопросов.

Масштаб проблемы

Атаки через скрипты установки — не редкость. Исследователи безопасности задокументировали сотни случаев, когда вредоносные пакеты использовали хуки postinstall или preinstall для:

• Кражи учётных данных — токенов GitHub, npm, облачных провайдеров, переменных окружения
• Эксфильтрации данных — файлов пакетов, конфигурации, исходного кода приложения
• Установки постоянного доступа — бэкдоров в CI/CD пайплайнах, модификации .bashrc
• Распространения — использования украденных токенов для публикации скомпрометированных версий
• Майнинга криптовалют — на машинах разработчиков или CI-раннерах

Как другие менеджеры пакетов обрабатывают скрипты

npm — аутсайдер. Все остальные крупные менеджеры пакетов относятся к скриптам установки с подозрением:

Вывод очевиден: pnpm уже использует тот же механизм, который предлагает npm, и это не сломало экосистему. Deno и Berry доказывают, что другая модель жизнеспособна. Предложение npm наконец-то приводит его в соответствие с остальной экосистемой.

Что делать разработчикам ПРЯМО СЕЙЧАС

Ещё до внедрения RFC (а RFC в npm исторически занимают от месяцев до лет) есть конкретные шаги, которые стоит предпринять сегодня.

1. Установите ignore-scripts=true в .npmrc

Это единственная самая эффективная мера безопасности:

# ~/.npmrc или .npmrc в корне проекта
ignore-scripts=true

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

# Установка с выполнением скриптов для конкретного пакета
npm install some-package --ignore-scripts=false

2. Проверьте зависимости на скрипты установки

Возможно, у вас уже есть пакеты, полагающиеся на скрипты установки. Найдите их:

# Список всех пакетов со скриптами жизненного цикла
npx npm-query-lifecycle-scripts

# Или вручную через package.json
find node_modules -name "package.json" -exec grep -l '"postinstall"\|"preinstall"\|"prepare"' {} \;

Типичные легитимные случаи использования скриптов установки:

• Нативные бинарники — sharp, node-gyp, esbuild компилируют или загружают бинарники под платформу
• Генерация кода — prisma generate, graphql-codegen
• Установка полифиллов — некоторые старые пакеты внедряют полифиллы при установке
• Уведомления — сообщения о финансировании или инструкции по настройке

3. Усильте CI/CD пайплайн

В CI/CD всегда используйте строгий режим:

# Лучшая практика CI/CD — не запускать скрипты установки
npm ci --ignore-scripts

# Затем сборка с явными шагами
npm run build

Руководство по миграции для авторов пакетов

Если вы поддерживаете npm-пакет, использующий скрипты установки, RFC влияет на вас напрямую. Когда npm сделает скрипты opt-in, разработчики могут не одобрить ваши скрипты — и пакет сломается молча.

Проверьте свои скрипты установки

Проверьте package.json на наличие скриптов жизненного цикла:

{
  "scripts": {
    "postinstall": "node postinstall.mjs",
    "preinstall": "node setup.mjs",
    "prepare": "husky"
  }
}

Спросите себя: действительно ли этот скрипт должен выполняться при установке? В большинстве случаев ответ — нет.

Мигрируйте на безопасные альтернативы

Общий тренд: улучшения безопасности npm в 2026

RFC по скриптам установки — не изолированное событие. 2026 год стал трансформационным для безопасности npm. Экосистема проходит через самое значительное ужесточение безопасности в своей истории.

Staged Publishing (npm 11.15.0)

Анонсированное на той же неделе, что и RFC, новое staged publishing в npm предоставляет период проверки перед публикацией пакетов. Это предотвращает атаки, когда злоумышленники публикуют вредоносные версии, мгновенно доступные миллионам разработчиков.

npm 12.0 Prerelease

Предварительная версия npm 12.0 уже опубликована. Хотя точный список изменений формируется, значительный скачок версии с 11.x указывает на серьёзные breaking changes — возможно, включающие RFC по скриптам установки или его раннюю реализацию.

Script Security GA (февраль 2026)

Функция Script Security npm, предупреждающая о пакетах со скриптами жизненного цикла при установке, стала общедоступной (GA) в феврале 2026. Это был первый шаг на пути к RFC — от предупреждений к блокировке по умолчанию.

Обязательная 2FA для популярных пакетов

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

Для безопасной веб-разработки — обращайтесь

Часто задаваемые вопросы

Безопасность начинается с осознания

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

Как разработчики, мы доверяли скриптам установки по умолчанию, потому что не было альтернативы. RFC это меняет. Экосистема переходит от "доверять по умолчанию, аудировать в исключениях" к "аудировать по умолчанию, доверять в исключениях". Это правильное направление.

Если вы создаёте веб-приложение и хотите работать с разработчиком, который серьёзно относится к безопасности зависимостей — не как к запоздалой мысли, а как к встроенной практике — свяжитесь со мной. Я full-stack разработчик с более чем 20-летним опытом, и каждый проект я строю с --ignore-scripts, зафиксированными зависимостями, проверками целостности lockfile и автоматическим сканированием безопасности с первого дня.