Новость
GitHub добавила stage-only токены npm для безопасной автоматизации
В npm появились granular-токены с правом только на предварительную публикацию. Автоматизация может отправить версию на проверку, но финальный выпуск подтверждает человек с 2FA.
Главное
Коротко: GitHub добавила для npm granular-токены с разрешением «Read and write (stage only)». Такой токен позволяет автоматическому процессу отправить новую версию пакета в очередь проверки, но не даёт выпустить её в реестр напрямую. Финальное подтверждение выполняет сопровождающий пакета с двухфакторной аутентификацией.
Изменение уже доступно как добровольная настройка и не меняет существующие токены. Текущую доступность платформы можно проверить на странице GitHub.
В материале
Как работает stage-only токен
- Владелец создаёт granular access token с правом «Read and write (stage only)» для нужных пакетов.
- Автоматизация использует команду
npm stage publishвместоnpm publish. - Версия попадает в очередь предварительной публикации.
- Сопровождающий проверяет пакет и подтверждает выпуск с 2FA.
Если workflow попытается выполнить обычный npm publish с таким токеном, npm отклонит запрос. Это действует и тогда, когда токен настроен на обход 2FA для автоматизации.
Что именно меняется в модели доступа
| Возможность | Обычный write-токен | Stage-only токен |
|---|---|---|
| Отправить версию на проверку | Да | Да |
| Опубликовать новую версию напрямую | Зависит от настройки | Нет |
| Перемещать dist-tags | Да | Да |
| Помечать версии устаревшими | Да | Да |
| Финальное подтверждение человеком | Не всегда | Требуется |
GitHub отдельно предупреждает, что stage-only токен всё равно сохраняет другие права записи. Например, с ним можно перемещать dist-tags и объявлять версии устаревшими. Поэтому секрет нужно защищать так же тщательно, как любой другой write-токен.
Какие требования указала GitHub
- пакет уже должен существовать в npm;
- пользователю нужен доступ на публикацию;
- в аккаунте должна быть включена 2FA;
- требуется npm CLI 11.15.0 или новее;
- требуется Node.js 22.14.0 или новее.
Stage-only токены дают путь перехода проектам, которые пока не могут использовать trusted publishing. GitHub связывает изменение с планом npm отказаться от прямой публикации через токены с обходом 2FA в январе 2027 года.
Почему ручное подтверждение важно
При прямой автоматической публикации скомпрометированный workflow потенциально способен отправить новую версию сразу в реестр. Стадирование добавляет точку проверки до того, как пакет станет доступен пользователям.
Это не заменяет анализ кода, контроль зависимостей и защиту репозитория. Человек должен проверить содержимое, версию, журнал сборки и происхождение артефакта, а не механически нажать подтверждение.
Как связана проверка на вредоносный код
В другом сентябрьском обновлении GitHub сообщила, что кнопка одобрения staged-пакета остаётся недоступной, пока не закончится проверка на вредоносный код. После завершения сканирования статус очереди обновляется, и сопровождающий может принять решение.
Для trusted publishing компания рекомендует сохранять конфигурации в режиме staging. Такая схема добавляет человеческое подтверждение и снижает вероятность того, что взломанный workflow опубликует пакет напрямую.
Что остаётся без изменений
- новая возможность включается добровольно;
- существующие токены продолжают работать по прежним правилам;
- stage-only не делает токен безвредным;
- права на dist-tags и deprecate нужно учитывать отдельно;
- решение не отменяет защиту репозитория и CI.
Командам не следует менять production-workflow без теста в отдельной среде. Перед переходом полезно проверить версии Node.js и npm CLI, определить ответственного за одобрение и продумать восстановление после отклонённой версии.
Контекст изменений GitHub
GitHub продолжает усиливать контроль цепочки поставки npm и развивать trusted publishing. Это дополняет другие изменения платформы, включая обновлённую работу с pull request и предстоящие изменения набора моделей GitHub Copilot.
Stage-only токены решают узкую задачу: отделяют автоматическую подготовку версии от решения о её публичном выпуске. Фактическая безопасность зависит от настроек репозитория, защиты секрета, проверки артефакта и дисциплины сопровождающих.
Что проверить перед переходом
- какие workflow сейчас используют прямой
npm publish; - есть ли у команды подходящий процесс проверки staged-версий;
- включена ли 2FA у сопровождающих;
- обновлены ли Node.js и npm CLI;
- защищены ли все оставшиеся токены с правом записи.
Не публикуйте значения токенов в задачах, логах и снимках экрана. Если секрет оказался раскрыт, его нужно немедленно отозвать и проверить историю действий пакета.