npm ужесточает правила для granular access tokens с обходом 2FA. Что это меняет для CI/CD: автоматизация больше не должна иметь полномочия живого администратора, даже если раньше это было удобно.

31 июля GitHub сообщил: токены npm, настроенные на bypass 2FA, больше не смогут выполнять чувствительные операции с аккаунтом, организацией и пакетами. Для таких действий потребуется интерактивная проверка вторым фактором.

Это не просто изменение настройки. Это пересмотр границы доверия.

Долгое время access token в пайплайне воспринимался как технический пользователь: выдали права, положили секрет в CI, настроили публикацию и забыли. Но токен не умеет отличать штатный релиз от скомпрометированного job. Если его украли, автоматизация получает тот же путь, который мы сами ей открыли.

В документации npm уже есть более безопасная базовая рекомендация для CI: для установки зависимостей и запуска тестов обычно достаточно read-only granular token с ограниченным доступом. Для публикации нужны другие механизмы и отдельная проверка.

Практический вывод для команды:

— разделить install и publish-пути;

— проверить, где в CI действительно нужны права на запись;

— убрать bypass 2FA там, где он больше не нужен;

— заменить долгоживущие секреты на короткоживущую федерацию или trusted publishing, если это поддерживается вашим сценарием;

— провести ревизию токенов не только в основном репозитории, но и в старых workflow, форках и скриптах релиза;

— добавить в runbook понятный план восстановления публикации после отказа интерактивной проверки.

Самая неудобная часть таких изменений в том, что безопасность проявляется не в новом экране, а в сломанном старом процессе. Пайплайн внезапно перестаёт публиковать пакет — и команда обнаруживает, что никто не знает, кому принадлежит этот токен и почему он вообще имел такие права.

Хорошая автоматизация должна быть не максимально самостоятельной, а минимально достаточной. Если действие можно выполнить read-only токеном, ему не нужен write-доступ. Если публикация требует доверия, это доверие должно быть коротким, наблюдаемым и отзывным.

Как у вас разделены права между установкой зависимостей, сборкой и публикацией пакетов?

#cybersecurity #devops #cicd #opensource #supplychainsecurity #izagprog