Практический разбор · GitHub Actions
GitHub Actions: ограничьте права GITHUB_TOKEN
Права GITHUB_TOKEN задаются на уровне организации, репозитория, workflow и job. Начните с read-only по умолчанию и выдавайте write только конкретной задаче, особенно для workflow из pull request и Dependabot.
Кому нужно проверить
Владельцам репозиториев и командам DevOps, которые поддерживают GitHub Actions. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Workflow может использовать GITHUB_TOKEN для чтения или изменения ресурсов репозитория. Слишком широкие права увеличивают последствия ошибки в action или скрипте. Для fork pull request GitHub обычно снижает write permissions до read-only, но настройки репозитория могут изменить это поведение; секреты и привилегированные deployment jobs требуют отдельной границы доверия.
Затронутые версии
Руководство относится к workflow GitHub Actions, использующим автоматически выданный GITHUB_TOKEN. Итоговые права зависят от настроек организации/репозитория, ключа permissions, события запуска, fork и Dependabot.
Исправленные версии
Универсальной исправленной версии нет. Задайте минимальный набор permissions на уровне workflow/job, защищайте environments и не выдавайте write-токен недоверенному коду из pull request.
Что сделать
- 1Составьте перечень workflow, событий запуска, actions и операций GitHub API. Отметьте jobs, которые пишут tags, releases, issues, packages или deployment environments.
- 2Задайте на верхнем уровне workflow `permissions: read-all` либо `contents: read`, затем добавляйте только необходимые разрешения на уровне конкретной job.
- 3Проверьте pull_request из fork, pull_request_target и workflow, запускаемые Dependabot. Не выполняйте недоверенный код с write-токеном или доступом к secrets.
- 4Закрепляйте сторонние actions по полному commit SHA или контролируемым версиям и используйте Dependabot для обновления. Избегайте передачи секретов в командную строку и логирование чувствительных значений.
- 5Для cloud deployment предпочитайте OIDC с узкой trust policy вместо долгоживущих cloud secrets. Защитите environments review и branch rules.
- 6Проверьте изменения на тестовой ветке: нужные шаги должны работать, а попытка выполнить лишнюю операцию должна получать отказ. Просмотрите permissions в итоговом workflow, а не только комментарии.
- 7После публикации регулярно пересматривайте токены, actions и self-hosted runners. При подозрении на компрометацию отзовите credentials, изучите workflow logs и историю изменений.
Примеры конфигурации и проверки
sed -n '1,120p' .github/workflows/ci.ymlRead-only проверка локального workflow-файла перед code review. Команда ничего не меняет, но путь может отсутствовать. Ищите явный permissions и не публикуйте строки с секретами или внутренними путями. Этот просмотр не вычисляет итоговые права GitHub для всех событий; проверьте документацию и настройки репозитория. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.