Разработчики pnpm выпустили версию 11.0 и включили по умолчанию защиту от слишком свежих пакетов из npm. Теперь менеджер пакетов не будет устанавливать новую версию зависимости, пока с момента публикации не пройдут 1440 минут — то есть одни сутки. Это касается прямых и транзитивных зависимостей.
Механизм называется minimumReleaseAge. Идея простая: вредоносные версии популярных пакетов часто живут в реестре недолго, но успевают попасть в CI/CD, локальные окружения разработчиков и автоматические обновления. Задержка даёт экосистеме время заметить подозрительный релиз, удалить его из реестра и не пустить в сборку самый опасный «нулевой час». Согласно документации pnpm, вредоносные релизы часто находят и удаляют в течение первых часов.
pnpm 11 также включает по умолчанию blockExoticSubdeps. Эта настройка запрещает транзитивным зависимостям тянуть код из нестандартных источников вроде Git-репозиториев или прямых ссылок на tarball, если такие источники не являются доверенными. Для атак через цепочку поставок это важный нюанс: лишний неожиданный источник в дереве зависимостей часто превращается в слепую зону для команды.
Ещё одно изменение — новая модель allowBuilds. Она заменяет старые настройки для управления пакетами, которым разрешено выполнять сборочные скрипты при установке. Для безопасности это чувствительная зона: preinstall и postinstall давно используются в атаках на npm-пакеты, потому что позволяют запустить код прямо во время установки зависимости.
Полностью отключить задержку можно через minimumReleaseAge: 0 в pnpm-workspace.yaml. Для срочных исправлений есть minimumReleaseAgeExclude: туда можно добавить пакет, группу пакетов или конкретную версию, которой разрешено обновляться сразу.
Обновление не сводится к безопасности. pnpm 11 требует Node.js 22 или новее, прекращает поддержку Node.js 18–21, переводит сам pnpm на pure ESM, меняет работу глобальных установок и переносит индекс хранилища на SQLite. Командам с монорепозиториями стоит проверить конфигурацию до миграции: часть старых настроек сборки удалена, а непрофильные параметры больше не читаются из .npmrc.
Так pnpm сделал безопасное поведение настройкой по умолчанию. Это не заменяет аудит зависимостей и lockfile, но снижает шанс поймать свежий вредоносный релиз просто потому, что сборка первой последовала за latest.
Командам, использующим pnpm 11 с новыми настройками по умолчанию, следует проверить существующие записи pnpm-workspace.yaml на наличие каких- onlyBuiltDependencies либо ignoredBuiltDependencies изменений и перенести их на новую allowBuilds карту.
Командам, стремящимся снизить риски, связанные с выполнением установки, следует рассматривать minimumReleaseAge в качестве базового контроля и наличие резервного пути для экстренных обновлений minimumReleaseAgeExclude.
Для монорепозиториев или сред, использующих прямые зависимости, полученные из Git, blockExoticSubdeps следует тщательно проверить значение по умолчанию, чтобы избежать нарушения разрешения для преднамеренно экзотических источников в файлах верхнего уровня package.json, поскольку этот параметр ограничивает использование таких источников только транзитивными зависимостями.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
