CodeScoring, Санкт-Петербург - Инструменты безопасной и качественной разработки / Посты

GitHub выпустил npm 12 и пометил его как latest 8 июля 2026 года. Для прода это не «ещё одна настройка package.json», а смена дефолта: старый удобный путь выполнения чужого кода при npm install наконец прикрывают.

Автоматизация, которая годами жила на доверии к транзитивным пакетам, получит предсказуемый эффект: где-то упадёт сборка. И это хороший лог. Хуже — когда она не падает, а скачивает сюрприз в postinstall.

allowScripts вместо надежды на lockfile

Раньше скрипт зависимости мог стартовать автоматически при установке. В npm 12 проект должен заранее разрешить это через allowScripts. Ограничение касается и явных lifecycle-скриптов, и неявной компиляции нативных модулей через node-gyp.

Для уже существующего дерева npm предлагает:

npm approve-scripts --allow-scripts-pending

Команда показывает зависимости, для которых ещё не принято явное решение, и помогает сохранить настройки в package.json. Это не магия и не антивирус. Просто список мест, где репозиторий раньше делегировал выполнение кода неизвестно кому. Наконец-то этот костыль стал видимым.

В CodeScoring связывают изменение с атаками через цепочку поставки. Вредоносные версии пакетов Shai-Hulud использовали postinstall, а Shai-Hulud 2.0 — preinstall. npm 12 закрывает именно автоматический запуск кода во время установки. Пакет всё ещё способен попасть в реестр и dependency tree, а код — сработать позднее при импорте приложением или системой сборки. То есть расслабляться рано: поменялся один участок attack surface, не весь маршрут.

Git-зависимости больше не проскочат боком

Новый режим относится не только к скриптам. Git-зависимости потребуют --allow-git, удалённые архивы — --allow-remote. В июньском анонсе npm отмечал, что Git-зависимости позволяли выполнить код даже при использовании --ignore-scripts.

Это место особенно любят старые фронтенд-репозитории: в package.json годами лежит ссылка на ветку чужого Git-репо, потому что «в npm тогда не успели выкатить фикс». Потом ветка меняется, CI тянет новый коммит, а команда долго дебажит, почему стейдж внезапно стал другим. Поп-хроника меняется быстрее, но и у вирусных образов и шоу хотя бы нет доступа к вашему runner.

Проверить стоит три вещи: какие зависимости действительно используют install-скрипты, откуда в проекте взялись Git-зависимости и внешние архивы, а также не завязана ли сборка на их неявную установку. Отдельно прогоните обновление npm на CI, а не первым делом на продовом образе. Да, это банально. Банальнее только искать причину красного пайплайна после ночного деплоя.

Токены публикации тоже попали под ревизию

Одновременно npm начинает ограничивать токены, позволяющие обходить двухфакторную аутентификацию. По данным CodeScoring, в начале августа 2026 года такие токены потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями; позднее они не смогут напрямую публиковать пакеты.

Для автоматической публикации GitHub рекомендует доверенную публикацию через OIDC либо публикацию с ручным подтверждением. Практический вывод простой: найдите в CI долгоживущие токены с правами на публикацию, пока они не превратились в ночной инцидент. Заодно сохраните lockfile, package.json и конфиги пайплайнов. Бэкапы — не паранойя. Это минимальный уровень взрослой разработки.