gha-security-review

gha-security-review — эксплуатационно-ориентированная проверка безопасности GitHub Actions. Навык предназначен для ревью workflow, composite actions и конфигурации, которую workflow загружает во время выполнения. Он ищет не общий список плохих практик, а уязвимость, которую может использовать внешний атакующий без права записи в репозиторий. Такой атакующий может открыть pull request из fork, создать issue или написать комментарий, но не может сам запустить workflow_dispatch и другие ручные workflow. Поэтому сначала нужно классифицировать триггеры и проверить, действительно ли путь до опасного шага доступен из внешнего события. В область просмотра входят .github/workflows/*.yml, action.yml и action.yaml, локальные actions в .github/actions, а также связанные CLAUDE.md, AGENTS.md, Makefile и shell-скрипты под .github. Навык отдельно просит проследить конфигурацию, которую pipeline читает из checkout: наличие такого файла может превратить безобидный pull request в путь к выполнению команд. Репозитории и workflow других проектов не входят в scope; GitHub App installation permissions можно только отметить как зависимость, но не выдавать за найденную уязвимость. Проверка начинается с pull_request_target и checkout кода из fork: опасная комбинация появляется, если workflow затем исполняет fork-код, локальный action или скрипт из такого checkout. Для run-блоков нужно собрать все выражения ${{ }}, отделить контролируемые внешним пользователем значения от числовых идентификаторов, SHA и имени репозитория и подтвердить, что выражение попадает именно в shell. Отдельные проверки охватывают issue_comment без author_association, доступность PAT и deploy key для недоверенного кода, кражу credentials, незафиксированные сторонние actions, permissions, secrets, self-hosted runners, cache и artifacts. Supply-chain проблема учитывается только когда сторонняя action имеет привилегии, секреты, OIDC, write token, release, deploy, package или signing-доступ. Каждая находка должна иметь связный сценарий эксплуатации. Для HIGH нужны точка входа, payload, механизм исполнения, влияние и краткий PoC: например, недостаточно сказать, что в YAML есть переменная, нужно показать, кто её контролирует и какой шаг выполнит значение. Навык принимает только HIGH и MEDIUM confidence; теоретические и LOW-сигналы не превращаются в отчёт. Перед публикацией результата требуется прочитать полный workflow, проверить trigger и все if-условия, проследить checkout или expression injection и убедиться, что существующая mitigation не закрывает путь. Без полного пути атаки проблема отбрасывается либо помечается как требующая проверки. Есть и явные безопасные границы: pull_request_target без checkout fork-кода сам по себе не считается pwn request; числовой pull_request.number в run, выражения в if и with, secrets как таковые, SHA-пиннинг и локальные actions не являются expression-injection или supply-chain finding без дополнительного пути. workflow_dispatch, schedule и push в защищённую ветку требуют доступа, которого внешний атакующий не имеет, поэтому такие случаи не входят в эту модель угроз. Практический результат навыка — короткий отчёт с подтверждёнными сценариями и исправлением, а не автоматическое изменение workflow. Он помогает найти реально достижимую компрометацию CI/CD, но не заявляет, что отсутствие находки является сертификатом безопасности всей GitHub-организации.