pnpm 11 выходит с новыми мерами защиты supply chain, включенными по умолчанию, и эта деталь важнее самого списка функций. Именно настройки по умолчанию определяют, что происходит в длинном хвосте сценариев: в свежих CI-окружениях, у новых контрибьюторов при install и в автоматизации, которая не будет читать ваш security wiki.
Главные изменения: однодневный Minimum Release Age, прежде чем только что опубликованные версии смогут участвовать в resolution, блокировка exotic subdependencies по умолчанию и новая модель Allow Builds для управления тем, каким зависимостям разрешено запускать build scripts.
Что в pnpm 11 важно проверить в первую очередь?#
Главное практическое изменение в pnpm 11 — перенос нескольких supply-chain controls в установку по умолчанию. Командам стоит проверить, совпадают ли задержка свежих релизов, блокировка exotic dependencies и явные разрешения build scripts с тем, как реально работают их CI, локальные окружения и процессы обновления зависимостей.
Definition: execution во время install#
Execution во время install — это код, который запускается package manager’ом при установке зависимостей, чаще всего через lifecycle scripts или build scripts. Риск в том, что install часто выполняется на ноутбуках разработчиков и в CI runners, где уже доступны tokens, credentials или signing keys.
Какой контроль pnpm 11 приоритизировать?#
| Контроль | Когда использовать | Что проверить |
|---|---|---|
| Minimum Release Age | Нужна задержка перед попаданием совсем свежих версий в installs. | Exact pins и старые вредоносные версии требуют отдельного контроля. |
| Блокировка exotic subdependencies | Нужно, чтобы dependency graph чаще шел через обычный registry resolution. | Часть легитимных пакетов может зависеть от Git или tarball источников. |
| Allow Builds | Нужны явные разрешения для зависимостей, запускающих build scripts. | Native modules и tooling packages могут требовать узких документированных исключений. |
Для внедрения свяжите проверку pnpm с Security Guides, OPSEC Guides и практическим threat-modeling чеклистом. Так решение по package manager не останется отдельной заметкой, а попадет в контекст dependency ownership, CI permissions и incident response.
Что изменилось в pnpm 11#
pnpm 11 меняет базовую модель установки тремя способами:
-
Minimum Release Ageпо умолчанию составляет 24 часа (1440 минут). Новые версии пакетов не участвуют в resolution, пока им не исполнится как минимум один день. -
Exotic subdependenciesтеперь блокируются по умолчанию. В этой трактовкеexotic— это транзитивные зависимости, которые резолвятся из нестандартных источников (например, Git-репозиториев или прямых URL на tarball), а не через обычный registry resolution. -
Новая модель
Allow Buildsуправляетbuild scriptsзависимостей. Вместо распределения политикиbuild scriptsпо нескольким настройкам, pnpm 11 вводит единую модель, в которой команды задают map из шаблонов имен пакетов в boolean-значения.
Каждое из этих правил можно переопределить, но ключевой сдвиг в том, что механизмы безопасности стартуют в состоянии on, если команда явно не решит иначе.
Зачем нужны эти defaults — и что они реально дают#
В посте Socket этот релиз рассматривается в контексте Mini Shai-Hulud, описанной как supply chain campaign, скомпрометировавшей пакеты в npm, PyPI и Packagist. Описанная механика знакома: preinstall- или import-time hooks, использовавшиеся для загрузки платформенно-специфичного runtime Bun и запуска обфусцированного credential stealer, нацеленного на secrets разработчиков и CI/CD.
Смысл не в том, что pnpm 11 «решает» эту кампанию end-to-end. В посте прямо сказано, что pnpm 11 не предотвратил бы все ее этапы. Более полезное утверждение уже: defaults pnpm 11 нацелены на условия, которые помогают современным компрометациям быстро распространяться — свежие вредоносные версии, execution во время install и неожиданные источники зависимостей.
Эти условия снова и снова встречаются в реальных инцидентах, потому что эксплуатируют одну и ту же структурную реальность: установка зависимостей автоматизирована, происходит часто и нередко запускается с доступом к ценным environment variables.
Minimum Release Age: встроенная задержка для свежих версий#
Самый прямой механизм — это Minimum Release Age, который по умолчанию равен одному дню. При такой настройке только что опубликованная версия не может участвовать в resolution, пока не пройдет 24 часа.
Это нацелено на конкретный паттерн «скорости», типичный для supply chain attacks. Когда атакующий компрометирует аккаунт мейнтейнера или token, он может опубликовать вредоносную версию и рассчитывать на:
semver-диапазоны, позволяющие автоматически подтянуть новую версию,- автоматические прогоны CI, стартующие из чистых окружений,
- разработчиков, запускающих
installбез pinning.
В это первое окно после публикации detection и response часто отстают от распространения. Принудительный период ожидания снижает экспозицию в самой рискованной фазе: сразу после того, как вредоносный релиз стал доступен.
Это не гарантия безопасности. Механизм не поможет, если вредоносная версия останется доступной достаточно долго, или если организация pin’ит точные версии (это хорошо для reproducibility, но меняет набор применимых рисков, связанных со «скоростью»). Он также не защищает от атак, приходящих через уже «состарившиеся» пакеты. Тем не менее как default это повышает стоимость стратегии «ударить быстро и исчезнуть быстро».
Блокировка exotic subdependencies: меньше скрытых путей в ваш dependency graph#
pnpm 11 также по умолчанию блокирует exotic subdependencies. Под ними понимаются транзитивные зависимости, приходящие не из registry, а из таких источников, как Git-репозитории или прямые URL на tarball.
Их блокировка сужает класс неприятных сюрпризов:
- не-registry источники сложнее анализировать и мониторить;
- они могут обходить ожидания команды насчет provenance и registry-based scanning;
- они добавляют ребра в dependency graph, которые труднее предсказать, аудировать и воспроизводить.
Этот механизм не позиционируется как прямое решение для любого компромета, опубликованного через registry. Многим атакам вообще не нужны exotic-источники. Но, как отмечает пост, supply chain campaigns «редко полагаются только на одну технику». Устраняя один тихий путь, вы сокращаете комбинаторные возможности атакующего, который пытается спрятать код в большом дереве зависимостей.
Allow Builds: более понятная политика для execution во время install#
Lifecycle scripts и build scripts остаются одним из самых часто используемых путей execution в атаках на npm ecosystem, потому что запускаются во время установки — часто на ноутбуках разработчиков и в CI runners, рядом с token’ами, credentials или signing keys.
pnpm 11 вводит модель Allow Builds, которая должна консолидировать и упростить управление build scripts. В посте она описывается как замена раздробленной политики единым, более понятным механизмом контроля.
Даже если конкретные настройки все еще можно менять под нужды команды, общий смысл нового подхода прост: контроль над install-time execution становится более явным, централизованным и управляемым.
В практическом смысле это важно потому, что вредоносные пакеты часто опираются именно на код, который выполняется во время install. Чем проще команде задать четкую политику о том, кто вообще может запускать build scripts, тем ниже риск случайно разрешить execution там, где его не ожидали.
FAQ#
Убирает ли pnpm 11 риск supply-chain атак в npm?#
Нет. Новые defaults снижают риск быстрых вредоносных релизов, неожиданных источников зависимостей и execution во время install, но не заменяют dependency review, аккуратный lockfile, изоляцию CI, минимизацию секретов и мониторинг инцидентов.
Нужно ли отключать новые defaults, если install сломался?#
Не сразу. Поломка означает, что в dependency graph скрыто решение по политике. Проверьте, какому пакету нужно исключение, почему ему нужен нестандартный источник или build step, и сделайте это исключение максимально узким.