GitHub встроил в npm новый этап согласования релиза: в npm CLI версии 11.15.0 появилась схема staged publishing, которая добавляет ручное подтверждение перед публичным выходом пакета. Для тех, кто живет на CI/CD, токенах и ночных релизах, это не косметика, а еще один барьер против сценария, когда взлом одного аккаунта превращается в проблему для всей цепочки поставок.
О нововведении сообщает The Register. Суть механики проста: вместо прямого npm publish разработчик или автоматический пайплайн может отправить пакет в промежуточную зону через npm stage publish, после чего мейнтейнер должен отдельно одобрить выпуск с двухфакторной аутентификацией, либо через CLI, либо через npmjs.com. Пока такого подтверждения нет, пакет не становится публичным.
На практике это меняет самую неприятную часть современной публикации зависимостей: автоматизация умеет собирать, тестировать и выкладывать артефакты, но плохо дружит с дополнительной проверкой личности в критический момент. Раньше у команд был не самый приятный выбор. Либо держать процесс максимально автоматизированным и надеяться, что токены не утекут. Либо усложнять релизный контур ручными действиями и постоянной возней с повторной авторизацией. Новый подход пытается совместить оба мира: сборка и подготовка пакета идут автоматически, а финальное решение о публикации принимает человек с 2FA.
Почему это вообще понадобилось, вопрос риторический. За последние годы атаки на экосистемы пакетов стали почти рутиной. Вместо того чтобы взламывать тысячи конечных компаний по одной, злоумышленники все чаще бьют по мейнтейнерам популярных библиотек и по учеткам, через которые публикуются обновления. Один скомпрометированный пакет, особенно популярный, дает быстрый доступ к огромному числу downstream-проектов. В декабре 2025 года на фоне кампании Shai-Hulud 2.0, в которой были скомпрометированы программные пакеты, GitHub уже анонсировал набор мер для усиления безопасности издателей npm-пакетов. Теперь одна из этих мер перешла из обещаний в рабочий инструмент.
Сам термин staged publishing в документации звучит почти буднично, но по сути речь о модели gated publishing, то есть публикации через явный пропускной пункт. Идея не новая: The Register напоминает, что ее обсуждают как минимум с 2020 года. Зато сейчас у нее наконец появилась прикладная форма внутри официального CLI и реестра. Для npm это важный сигнал: проблема уже не воспринимается как частный инцидент отдельных команд, она стала инфраструктурной.
Отдельный смысл новинка имеет для тех, кто строит безопасную публикацию пакетов через автоматические workflow. Именно такие процессы чаще всего опираются на токены, а токены, в отличие от человека с 2FA, можно украсть, скопировать или случайно засветить. Чем дольше живет токен, тем интереснее он для атакующего. Поэтому GitHub ранее отказался от долгоживущих classic tokens и начал продвигать более короткие по сроку сессионные токены и ограниченные по правам access tokens для автоматизации. На бумаге это выглядит правильно. В реальной жизни разработчики быстро выяснили, что токены, которые истекают каждые 90 дней или раньше, дисциплинируют не только безопасность, но и нервы команды. Перегенерация, перепривязка, отладка пайплайнов, внезапно умершие секреты перед релизом — знакомый список.
На этом фоне staged publishing выглядит как прагматичный компромисс, а не как еще один пункт в чеклисте комплаенса. Команда может оставить автоматическую подготовку релиза, не заставляя инженеров каждый раз ломать процесс ради немедленного прохождения 2FA. Пакет сначала попадает в staging-зону, а одобрение можно дать позже, в удобный момент, уже с человеческой проверкой. Для небольших команд это шанс не выбирать между безопасностью и скоростью. Для крупных организаций — способ отделить этап сборки от этапа окончательного допуска в публичный реестр.
Есть и второй слой контекста. GitHub уже предлагает trusted publishing, то есть публикацию через доверенную связку между npm и CI/CD-провайдером на базе OpenID Connect. Это более современный подход, при котором не нужно хранить секреты в старом стиле. Но у него, по данным The Register, остается заметное ограничение: OIDC-механизм по-прежнему не работает при первой публикации пакета. Иными словами, полностью закрыть все сценарии одной только «доверенной публикацией» пока нельзя. В паре со staged publishing картина выглядит лучше: автоматизация отвечает за сборку и доставку артефакта до точки проверки, а человек подтверждает выпуск там, где риск ошибки или компрометации особенно дорог.
Для русскоязычной аудитории тут важен не только npm как таковой. Похожая логика постепенно становится отраслевым стандартом: любые популярные репозитории пакетов будут двигаться к более дробному контролю над релизом, уменьшению срока жизни учетных данных и разнесению полномочий между машиной и человеком. Если у вас продукт, SDK или внутренняя платформа завязаны на open source-зависимости, это означает две вещи. Первая: безопасность публикации пакетов становится частью инженерного процесса, а не задачей «того парня из AppSec». Вторая: зрелость команды все чаще измеряется не скоростью выкладки, а тем, насколько трудно использовать ее же автоматизацию против нее самой.
Открытый вопрос теперь не в том, нужен ли npm дополнительный контроль публикаций, а в том, насколько быстро мейнтейнеры и компании реально перестроят свои процессы под эту модель. Инструменты GitHub дает, но защита цепочки поставок не включается по умолчанию от одного факта существования новой команды в CLI. Для тех, кто хочет проверить детали первоисточника, материал доступен у The Register .
The post npm добавил ручное подтверждение публикаций пакетов appeared first on iTech News.