Публикация в npm и PyPI: привязка идентичности издателя к одобренным артефактам релиза

Что это

Состояние на 25 октября 2026 года. Trusted publishing обменивает подтверждение идентичности CI на временные учётные данные реестра вместо хранения постоянного токена публикации. Перед изменением процесса выпуска повторно проверьте, каких провайдеров поддерживают реестры, какие ограничения действуют для раннеров и какие настройки требуются. Приведённая документация — обновляемый справочный источник, полученный для этого обзора, а не датированный бюллетень об инциденте.

Для npm в документации указаны следующие предварительные условия: npm CLI 11.5.1 или новее и Node 22.14.0 или новее. Эта статья посвящена рабочим процессам GitHub Actions, которые публикуют npm-пакеты или дистрибутивы Python в PyPI.

Почему это важно

Модель безопасности PyPI прямо возлагает ответственность за целостность рабочего процесса на издателя. Временные учётные данные остаются конфиденциальными, и скомпрометированный разрешённый рабочий процесс может их получить. Отказ от сохранённых токенов снижает риск раскрытия учётных данных, но не делает выполнение зависимостей безопасным.

Документация npm о происхождении пакетов разграничивает проверяемую связь с исходным кодом и инструкциями сборки и гарантию безвредности кода. Практический вывод прост: разрешённый конвейер может заверить и вредоносный артефакт. При одобрении следует оценивать исходные компоненты и результат выпуска, а также то, от чьего имени он подписан.

Как применять

• Точно укажите нужного владельца, репозиторий и рабочий процесс публикации при регистрации. В настройках GitHub для npm введите имя файла рабочего процесса и свяжите необязательное имя окружения с защищённым окружением публикации. Прежде чем убирать прежний способ аутентификации, сопоставьте настроенную идентичность с фактическим заданием.
• Следуйте схеме разделения PyPI: задание сборки создаёт дистрибутивы; небольшое задание публикации получает и загружает их. Выдайте permissions: {id-token: write} только тому заданию, которому нужен OIDC. Установка зависимостей, тесты и недоверенные изменения должны оставаться вне полномочий этого задания.
• Настройте проверяющих для окружения, запретите одобрение собственных запусков, ограничьте ветки или теги для выпуска и отключите обход защиты администратором, где это поддерживается. Проверьте доступность функций для репозитория и тарифного плана. По умолчанию GitHub разрешает администраторам обходить защиту окружения; одного имени окружения недостаточно.
• Сделайте одобрение предметным: зафиксируйте в записи о выпуске ревизию исходного кода, запуск сборки и дайджест артефакта, затем опубликуйте именно проверенные байты. Сопоставьте идентичность в аттестации и сведения об исходном коде с этой записью. Расследуйте несовпадения, а не принимайте значок подтверждённого происхождения за решение о выпуске.
• Проверяйте код рабочих процессов и сторонние actions. Предоставляйте токенам репозитория минимальные права и закрепляйте actions на проверенных полных идентификаторах коммитов. Никогда не выводите учётные данные и не печатайте всё окружение для отладки. GitHub предупреждает, что автоматическое маскирование журналов может не сработать, в том числе при преобразовании значений; проверяйте журналирование как при ошибках, так и при успешных запусках.
• После перехода удалите неиспользуемые токены публикации и проверьте регистрации доверенных издателей. В PyPI регистрации принадлежат проектам и сохраняются после удаления создавшего их пользователя. Явно включите их в процедуру отзыва доступа уходящих сопровождающих.

Подводные камни

Этап одобрения не компенсирует компрометацию аккаунта проверяющего или непроверенные изменения самого механизма одобрения. Повторно используемый кэш сборки и постоянный раннер требуют отдельной оценки доверия. Фиксируйте неуспешные проверки идентичности или артефакта как ошибки выпуска; незаметный переход к сохранённому токену записи подрывает смысл этой защиты.