GitHub представил новый тип npm-токенов, который позволяет автоматизированным пайплайнам отправлять версии пакетов на проверку, но не публиковать их напрямую в реестр. Решение появилось на фоне серии громких supply chain-атак на npm в 2026 году и как промежуточный этап перед запланированным на январь 2027 года отказом от прямых публикаций через bypass-2FA токены.
Что меняется в работе с npm-токенами
При создании granular access token в настройках npm-токенов GitHub теперь доступна опция Read and write (stage only). Токен с этим уровнем доступа может выполнять команду npm stage publish — она отправляет версию пакета в «стейджинг», после чего мейнтейнер должен вручную подтвердить релиз через двухфакторную аутентификацию (2FA). Прямой вызов npm publish с таким токеном будет отклонён, даже если в настройках токена указан обход 2FA.
При этом stage-only токены сохраняют остальные права на запись в пакет: перемещение dist-tags, депрекацию версий и другие операции, не связанные с непосредственной публикацией. GitHub подчёркивает, что к таким токенам нужно относиться с той же осторожностью, что и к любым другим токенам на запись.
Нововведение опционально: существующие токены и их возможности прямой публикации не меняются.
Контекст: supply chain-атаки 2026 года
Введение stage-only токенов — не изолированное изменение, а часть более широкой реакции на волну инцидентов в экосистеме npm, произошедших в 2026 году.
В марте 2026 года был скомпрометирован самый популярный HTTP-клиент JavaScript — Axios. Злоумышленник, используя украденные npm-учётные данные мейнтейнера, опубликовал две вредоносные версии (1.14.1 и 0.30.4), которые устанавливали кроссплатформенный RAT. Вредоносная зависимость была предварительно размещена на npm за 18 часов до атаки, чтобы обойти сигнатуры «нового пакета».
В мае 2026 года последовала атака на node-ipc — библиотеку с более чем 10 миллионами еженедельных загрузок. Три вредоносных версии одновременно (9.1.6, 9.2.3, 12.0.1) были опубликованы с аккаунта, не связанного с предыдущими релизами. Пейлоад объёмом 80 КБ собирал более 90 категорий учётных данных — от AWS-ключей и SSH-ключей до токенов Kubernetes и настроек Claude AI.
В августе 2026 года была скомпрометирована цепочка поставок keyv — популярного пакета для кэширования. Вредоносные релизы, помеченные как latest, выполняли obfuscated preinstall-скрипт, который загружал второй этап объёмом более 700 КБ. Snyk Security Research зафиксировала 11 вредоносных релизов, восемь из которых на момент анализа оставались на теге latest.
В июне 2026 года атаке подверглись пакеты в легитимном пространстве имён @redhat-cloud-services. Согласно отчёту Sonatype, пакеты выполняли heavily obfuscated скрипты при установке, которые загружали второй этап с возможностью кражи переменных окружения, AWS-учётных данных и репликации.
Почему это важно для CI/CD-пайплайнов
Основная проблема, которую решают stage-only токены — это компромисс между автоматизацией и безопасностью. Типичный CI/CD-пайплайн требует токен с правами на публикацию, чтобы выпускать новые версии пакетов. Однако такой токен, попав в руки злоумышленника (через компрометацию CI-окружения, логов или артефактов), позволяет опубликовать вредоносную версию без какого-либо контроля.
GitHub ранее анонсировал, что с января 2027 года удалит возможность прямой публикации через bypass-2FA токены. Stage-only токены — это миграционный путь для команд, которые ещё не перешли на trusted publishing с использованием OIDC (OpenID Connect), как это сделано, например, в официальном пайплайне Axios.
Trusted publishing, при котором публикация привязана к конкретному GitHub Actions workflow через OIDC, остаётся наиболее безопасным вариантом. Однако он требует более сложной настройки и не всегда доступен для проектов, использующих нестандартные CI-системы.
Практический чек-лист для команд
Если ваш проект использует npm-токены для автоматической публикации, стоит оценить текущую ситуацию:
— Проверьте, какие токены используются в CI/CD и есть ли среди них токены с правами на прямую публикацию. Если да, замените их на stage-only токены.
— Убедитесь, что на npm-аккаунте включена 2FA. Она обязательна для работы stage-only токенов.
— Обновите npm CLI до версии 11.15.0 или новее и Node.js до 22.14.0 или новее.
— Внедрите npm stage publish в пайплайн вместо npm publish. Это добавит шаг ручного ревью перед релизом.
— Если проект ещё не использует trusted publishing, рассмотрите возможность миграции на OIDC-привязку через GitHub Actions.
— Для проектов, где ручное ревью каждого релиза неприемлемо (например, автоматические патч-релизы), stage-only токены не являются полным решением — в таких случаях требуется trusted publishing.
Ограничения и что дальше
Stage-only токены не защищают от атак, при которых злоумышленник получает доступ к npm-аккаунту мейнтейнера и может подтвердить стейджированный релиз. Это защита на уровне автоматизации, а не на уровне управления доступом к аккаунту.
Кроме того, решение не решает проблему атак через компрометацию зависимостей, когда вредоносный код внедряется не через прямой publish, а через подмену пакета на этапе установки — как в случае с keyv или node-ipc.
GitHub рекомендует делиться вопросами и проблемами миграции в категории npm community discussion. Для тех, кто хочет глубже разобраться в механизме, опубликована документация по staged publishing.
На данный момент stage-only токены доступны для всех пользователей npm. Изменение не затрагивает существующие токены, но для команд, которые ещё не обновили свои пайплайны, это хороший повод пересмотреть подход к безопасности публикации до январского дедлайна 2027 года.