🛡 NPM 12 переводит скрипты зависимостей на безопасный дефолт После волны атак TeamPCP и самовоспроизводящегося червя Shai-Hulud, злоупотребивших автоматическим запуском preinstall/postinstall-скриптов, GitHub убирает дефолтное выполнение кода из зависимостей. Начиная с NPM 12 (релиз ожидается в июле) команда npm install больше не выполнит preinstall, install или postinstall-скрипты транзитивных и прямых пакетов, если им не дали явное разрешение. Под нож попали и неявные сценарии сборки: node-gyp для пакетов, где есть binding.gyp без явного install-скрипта, — ровно тот вектор, который эксплуатировал Shai-Hulud Miasma. Меняется и разрешение Git-зависимостей: прямые и транзитивные адреса к репозиториям перестанут обрабатываться при обычной установке, если только разработчик не разрешит их явно. Это закрывает внедрение кода через подмену .npmrc и Git-исполняемого файла. Удалённые URL-зависимости, включая HTTPS-тарболы, тоже требуют теперь явного флага --allow-remote (доступен с NPM 11.15.0). Как итог — классическая атака через «тяжёлую» транзитивную зависимость, тянувшую малварь через скрипт сборки, ломается на уровне менеджера пакетов. GitHub предлагает переходный инструмент: npm approve-scripts –allow-scripts-pending формирует белый список в package.json. С NPM 11.16.0 и выше разработчики уже получат предупреждения при запуске неразрешённых скриптов. После коммита белого списка и обновления до 12-й версии неразрешённые скрипты просто не стартуют. По данным SecurityWeek, это крупнейшее изменение модели безопасности NPM за последние годы. Две недели до NPM 12 — и это окно возможностей: атакующие наверняка попытаются впихнуть максимум малвари до релиза. Любопытнее всего судьба CI/CD-конвейеров: команда npm approve-scripts требует интерактивного подтверждения, и я ожидаю всплеска кривых скриптов «echo y | npm approve-scripts», которые превратят белый список в мёртвый груз. Тот же класс проблем десять лет назад убил смысл DNSSEC-валидации у половины внедривших — ручной контроль требует дисциплины, а не инструмента. #NPM #supplychain #DevSecOps #NodeJS