[Перевод] OIDC настроен. Почему ваши GitHub Actions всё ещё уязвимы?

Последние два года я повторяю командам, с которыми работаю, одну и ту же фразу: «переходите на OIDC и убирайте AWS_ACCESS_KEY_ID из GitHub Secrets». Этот совет по-прежнему актуален. Но после атак в мае 2026 года — сначала на actions-cool/issues-helper, а затем Megalodon с его 5 561 репозиторием-ловушкой — я формулирую его уже иначе.

Проблема не в OIDC. Проблема в том, что OIDC стали воспринимать как финальную точку в вопросах безопасности, хотя он должен быть лишь отправной точкой. Две майские атаки устроены по-разному, но обе эксплуатируют одну и ту же забытую границу доверия — раннер CI/CD.

В случае с actions-cool/issues-helper атакующий подменяет теги action и добивается выполнения подложного коммита, который может читать память процесса Runner.Worker. В случае с Megalodon он напрямую внедряет вредоносные workflow GitHub Actions в публичные репозитории и собирает переменные окружения, файлы с учетными данными, kubeconfig-файлы, SSH-ключи и OIDC-токены.

В обоих случаях вывод один: OIDC позволяет отказаться от статических учетных данных для доступа к облаку, но не делает безопасным код, который выполняется внутри job и получает доступ к временным учетным данным. Эта статья — поправка к тому, как я сам раньше объяснял эту тему. Я не собираюсь отказываться от рекомендации использовать OIDC. Я лишь хочу четко показать, какие меры нужно выстроить вокруг него, чтобы этот подход действительно работал в 2026 году.