🛡 npm staged publishing: 2FA-барьер перед каждым релизом GitHub добавил в npm механизм staged publishing — теперь пакет не уходит в реестр сразу после `npm publish`, а попадает в очередь ожидания, где мейнтейнер должен пройти 2FA-подтверждение и явно одобрить релиз. Это ломает классическую цепочку атаки через скомпрометированный CI/CD-токен: даже если атакующий получил доступ к пайплайну и OIDC-токену, без живого человека с 2FA пакет в реестр не попадёт. Функция доступна для пакетов, уже существующих в реестре, — новые пакеты через staged publishing не публикуются. Для работы нужен npm CLI версии 11.15.0 или новее, команда `npm stage publish` из корня пакета, и включённая 2FA на аккаунте. GitHub рекомендует совмещать staged publishing с trusted publishing через OIDC — тогда CI/CD генерирует токен, но окончательное слово остаётся за мейнтейнером. Параллельно добавили три новых флага для `npm install`: `--allow-file`, `--allow-remote` и `--allow-directory` — они дают явный контроль над тем, откуда вообще можно ставить пакеты, помимо реестра. Это прямой ответ на атаки через локальные тарболы и remote URL, которые активно использует группировка TeamPCP в своей самовоспроизводящейся схеме компрометации популярных пакетов, по данным The Hacker News. Для команд, которые используют npm в CI/CD, минимальный чеклист: обновить npm до 11.15.0+, включить staged publishing на критичных пакетах, добавить `--allow-remote=false` в корпоративные пайплайны где внешние URL в зависимостях не нужны. Staged publishing закрывает один конкретный вектор — автоматизированный push через скомпрометированный токен. Но он не защищает от мейнтейнера, которого уже скомпрометировали вместе с его телефоном. Реальная защита для корпоративного npm — это private registry с зеркалированием и политикой allowlist на уровне Nexus или Artifactory, а не 2FA на публичном реестре. Staged publishing полезен, но для open-source мейнтейнеров, а не для корпоративного DevSecOps. #npm #SupplyChain #DevSecOps #StagedPublishing