GitHub Actions Workflow Permissions Batch Auditor
Проверить сразу несколько workflow-файлов на слишком широкие permissions, позволяющие захват релизного пайплайна.
Как это работает
14 июля 2026 года атакующий скомпрометировал релизный пайплайн AsyncAPI не украв npm-токен, а воспользовавшись неправильно настроенным GitHub Actions workflow: получив push-доступ в ветку репозитория, он позволил легитимному CI самому опубликовать вредоносный пакет через настоящий release workflow с валидной провенанс-атрибуцией. Publish npm происходил от имени доверенного процесса, потому что workflow имел избыточные права. GitHub Actions Workflow Permissions Batch Auditor online проверяет сразу несколько workflow-файлов на именно такие избыточные permissions.
Ключевая уязвимость такого паттерна — сочетание триггера, реагирующего на внешний ввод (pull_request_target, push в ветку, доступную внешним контрибьюторам), с правами вроде contents: write или id-token: write, которые дают возможность закоммиченному коду инициировать реальную публикацию пакета через доверенную инфраструктуру CI.
Инструмент разбирает секцию permissions каждого вставленного workflow-файла, сопоставляет её с типом триггера, и явно предупреждает о комбинациях, исторически связанных с захватом релизных пайплайнов — не заменяя ручной security review, а указывая, с каких файлов стоит начать при аудите парка workflow организации.
Частые вопросы
Почему pull_request_target считается более рискованным триггером, чем обычный pull_request?
pull_request_target запускается с правами и секретами базового репозитория даже для PR из форков, в отличие от обычного pull_request, который выполняется в изолированном контексте форка без доступа к секретам — именно эта разница и делает pull_request_target удобной целью для атаки при неаккуратной настройке.
Достаточно ли просто убрать widest permissions, чтобы полностью исключить такой риск?
Это существенно снижает риск, но не устраняет его полностью — принцип наименьших привилегий (запрашивать только конкретные, минимально необходимые права для каждого job) остаётся лучшей практикой, а не просто общее сокращение списка разрешений.
Проверяет ли инструмент реальные секреты в самом workflow-файле?
Нет, фокус именно на секции permissions и типе триггера, а не на поиске секретов в тексте самого файла, для проверки секретов на сайте есть отдельные инструменты категории .env.
Можно ли проверить сразу все workflow-файлы организации одним прогоном?
Да, инструмент принимает несколько файлов сразу, разделённых пустой строкой, что удобно именно для аудита целого парка репозиториев организации, а не одного файла за раз.