Токены npm классического типа отозваны — срочный контрольный список для миграции для команд полного стека

Что произошло (кратко): Реестр npm от GitHub завершил запланированное усиление безопасности 9 декабря 2025 года — все устаревшие «классические» токены npm были навсегда отозваны, была введена аутентификация на основе сессий для локальных входов, и поддержка CLI для создания/управления гранулярными токенами доступа была добавлена. Это нарушает любые рабочие процессы, которые все еще полагаются на долгоживущие классические токены (CI-секреты, запеченные образы, скрипты развертывания, внутренние инструменты). (github.blog)

Почему это важно для команд полного стека

• Проблемы с публикацией/конвейерами: CI-задачи, которые используют классический NPM_TOKEN, теперь будут завершаться с ошибками аутентификации, часто без уведомления в процессе релиза. (github.blog)
• Увеличение дисциплины ротации и 2FA: Гранулярные токены записи по умолчанию имеют короткий срок действия и требуют более строгих правил 2FA/обхода для автоматизации — вам нужна ротация токенов/аттестация или публикация на основе OIDC. (github.blog)
• Скрытые учетные данные: Токены, запеченные в контейнерных образах, кэшах сборки или машинах разработчиков, перестают работать и могут потребовать исправления в различных местах (образы, облачные секреты, ~/.npmrc). (github.blog)

Что делать сейчас — приоритезированный контрольный список (выполните это сегодня)

1. Триаж: найдите все использования классических токенов npm

• Поиск в GitHub/GitLab/CI-секретах по NPM_TOKEN, файлам npmrc, Dockerfile и скриптам сборки. Не забудьте про самохостинг и облачные образы. Это самый важный шаг с точки зрения влияния. (github.blog)

2. Восстановите CI-публикацию (быстрое восстановление)

• Если вы публикуете из GitHub Actions или GitLab, примите «Доверенную публикацию» / OIDC, где это поддерживается — это исключает хранение долгоживущих токенов, выдавая короткие учетные данные на каждую сессию рабочего процесса. Если OIDC невозможен, создайте гранулярный токен доступа с минимально необходимыми правами и включите опцию CI «Обойти 2FA» для этого токена. Протестируйте репетицию публикации. (github.blog)

3. Ротация секретов и образов

• Замените любые секреты NPM_TOKEN новыми гранулярными токенами или перейдите на OIDC. Пересоберите и разверните любые контейнерные образы или образы ВМ, которые содержали классические токены. Проверьте логи CI на наличие ошибок 401/403 после ротации. (github.blog)

4. Обновления рабочего процесса локальных разработчиков

• Обучите инженеров: npm login теперь создает короткие (2-часовые) сессии для интерактивной публикации; для длительных локальных задач используйте гранулярные токены или примите OIDC на этапе разработки, где это возможно. Удалите долгоживущие токены из ~/.npmrc. (github.blog)

5. Обновите инструменты и реестры

• Частные реестры/прокси-устройства: подтвердите, что они поддерживают гранулярные токены и аутентификацию по сессиям. Если вы полагаетесь на старые менеджеры пакетов (Yarn v1/v2), имейте в виду, что устаревшая конечная точка была временно восстановлена во время развертывания — планируйте обновление, так как этот совместимый слой недолговечен. (github.blog)

6. Автоматизируйте ротацию и принцип наименьших привилегий

• Реализуйте политику ротации токенов (автоматическое обновление или короткие TTL), ограничьте области токенов до «только публикация» или только для чтения, где это возможно, и обеспечьте принцип наименьших привилегий на уровне пакетов и организаций. Интегрируйте ротацию в ваш менеджер секретов (Secrets Manager, Vault, GitHub Secrets + OIDC). (github.blog)

7. Проверка после миграции

• Проведите полные пробные публикации из CI и с локальных машин разработчиков. Подтвердите, что npm publish, npm pack и npm dist-tag работают как ожидалось и что происхождение пакета (когда доступно) фиксируется Доверенной публикацией/OIDC.

Быстрый план действий по исправлению (минимальные команды/шаги)

• Аудит: grep/secret-scan для NPM_TOKEN по репозиториям и образам.
• CI: переключите задачи публикации на использование OIDC (GitHub Actions: настройте разрешения id-token + доверенный издатель в настройках npm) или создайте гранулярный токен с точными правами + Обойти 2FA только для CI. (github.blog)
• Локально: дайте указание разработчикам выполнить npm login и удалить устаревшие токены из ~/.npmrc; предпочтите эфемерные сессии или гранулярные токены на уровне задачи. (github.blog)

Операционные подводные камни и ловушки

• Монорепозитории и скрипты рабочих пространств обычно повторно используют один токен — ротация этого одного секрета может привести к сбоям десятков пакетов одновременно. Распределите развертывание с репетицией публикации. (github.blog)
• CI-образы или кэши сборки, содержащие токены, должны быть пересобраны; в противном случае конвейеры будут сбойными даже после ротации секретов. (github.blog)
• Некоторые сторонние сервисы или старые инструменты могут по-прежнему ожидать классические токены; необходимы проверки по каждому поставщику. (github.blog)

Почему это стоит усилий Изменение существенно снижает радиус поражения от утечек долгоживущих учетных данных, заставляет соблюдать лучшую гигиену автоматизации (OIDC/доверенная публикация) и согласует реестр npm с более строгими, современными паттернами аутентификации — но это требует немедленной оперативной работы для команд, которые все еще зависят от устаревших токенов. (github.blog)

Дополнительное чтение (официальный журнал изменений)

Источник

• Источник