GitHub меняет базовые правила игры для npm: в версии 12, которую ждут уже в следующем месяце, команда npm install перестанет автоматически запускать часть install-скриптов и подтягивать некоторые типы зависимостей без явного разрешения. Для тех, кто отвечает за безопасность npm в продакшене, это не косметика, а довольно жёсткий разворот: привычная магия установки пакетов становится менее удобной, зато заметно менее доверчивой.
О грядущих изменениях сообщает BleepingComputer. Суть проста: всё, что раньше исполнялось или скачивалось по умолчанию во время npm install, теперь будет требовать явного одобрения. Под ограничение попадают preinstall, install и postinstall-скрипты зависимостей, сборки нативных модулей через node-gyp, а также prepare-скрипты для Git-зависимостей, локальных файлов и linked-пакетов. Если перевести это с языка менеджера пакетов на язык эксплуатации инцидентов: один из самых удобных путей для незаметного выполнения чужого кода во время сборки GitHub пытается закрыть на уровне дефолтного поведения.
Вторая важная перемена касается источников зависимостей. Начиная с npm v12, менеджер пакетов не будет автоматически забирать зависимости из Git-репозиториев, ни прямые, ни транзитивные, если это не разрешено явно. То же правило вводят для удалённых URL-зависимостей, например tarball-архивов по HTTPS. Это выглядит как удар сразу по двум болезненным местам экосистемы JavaScript. Во-первых, Git-зависимости давно считаются зоной повышенного риска, потому что живут вне основного реестра и легко обходят привычные ожидания разработчика от публикации пакета. Во-вторых, удалённые архивы и нестандартные источники удобны в легитимных сценариях, но так же удобны и для цепочек поставки, где вредоносный код пытаются провести не через публичный пакет, а через менее заметный маршрут.
GitHub отдельно объясняет, почему даже отключённых install-скриптов уже недостаточно. В случае с Git-зависимостями оставался путь к выполнению кода через конфигурацию: файл .npmrc мог повлиять на то, какой Git-исполняемый файл будет использован во время установки. Иными словами, даже если команда считала, что “скрипты мы давно запретили, значит всё под контролем”, в модели угроз оставалась ещё одна дверь. Новые ограничения как раз режут такие обходные траектории. Для DevSecOps-команд это важный сигнал: атаки на supply chain давно ушли от примитивного “подложили злой postinstall” и всё чаще используют особенности экосистемы, которые выглядят как нормальное поведение инструмента.
Почему GitHub решился на такой шаг именно сейчас, тоже понятно. За последние месяцы и годы npm-экосистема получила целую серию атак, где вредоносная логика срабатывала во время установки пакета или приходила через нестандартные источники зависимостей. В анонсе перечислены вполне конкретные кейсы: кампании с вредоносными preinstall и postinstall-скриптами, затронувшие eslint-config-prettier, пакеты Picasso от Toptal, десятки npm-пакетов для кражи данных, а также злоупотребления Git-зависимостями, описанные в атаках Shai-Hulud. Это уже не набор теоретических сценариев из презентации безопасников, а повторяющийся паттерн. Если установка зависимости автоматически даёт шанс выполнить чужой код, рано или поздно этим будут пользоваться не только исследователи, но и операторы реальных кампаний.
Для разработчиков и владельцев сборочной инфраструктуры новость хорошая и неприятная одновременно. Хорошая, потому что безопасность npm становится менее зависимой от дисциплины каждой отдельной команды: рискованные механики просто перестают считаться нормой по умолчанию. Неприятная, потому что у многих CI/CD-пайплайнов, внутренних пакетов и исторически сложившихся workflow есть все шансы внезапно сломаться после апгрейда. Особенно это касается проектов, где зависимость тянется из Git, где во время установки собираются нативные модули или где install-скрипты используются не как экзотика, а как часть легитимного процесса. GitHub предлагает подготовиться заранее: обновиться до npm 11.16.0 или новее и прогнать обычные сценарии установки. Эта версия уже показывает предупреждения о действиях, которые перестанут работать в npm 12. По сути, это режим мягкой диагностики перед тем, как инструмент начнёт говорить “нет” уже без предупреждений.
Для бизнеса вывод ещё приземлённее. Если компания живёт на Node.js, то вопрос теперь не в том, “нравятся ли нам новые дефолты”, а в том, насколько хорошо команда понимает происхождение своих зависимостей. Любая сборка, которая опирается на Git-репозиторий, tarball по URL или install-скрипт третьей стороны, должна быть либо осознанно одобрена, либо переписана. Это означает дополнительные проверки в пайплайнах, ревизию lockfile-цепочек и, возможно, чистку старых инженерных привычек, которые когда-то ускоряли релизы, а теперь выглядят как долговая расписка перед будущим инцидентом. Для российских команд, особенно тех, кто держит собственные зеркала пакетов, изолированные контуры и жёсткие требования комплаенса, такие изменения скорее ложатся в уже знакомую логику: доверяй меньше, разрешай точечно, фиксируй исключения явно.
GitHub уже открыл публичное обсуждение будущих изменений, так что часть деталей ещё могут подправить до финального релиза npm 12. Но общий вектор вряд ли изменится: эпоха, когда npm install молча делал слишком много полезного и слишком много опасного одновременно, подходит к концу. Главный вопрос теперь не в том, готовы ли разработчики к более строгим правилам, а в том, сколько старых процессов в экосистеме держались на неявном доверии и сколько из них начнут всплывать только тогда, когда менеджер пакетов впервые откажется исполнять чужой код по умолчанию.