Практический разбор · GitHub Actions
GitHub Actions self-hosted runner: отделите недоверенные workflow
Self-hosted runner выполняет код workflow в вашей инфраструктуре. Не подключайте runner с секретами и внутренней сетью к публичному репозиторию без сильной границы доверия и контроля жизненного цикла.
Кому нужно проверить
Администраторам CI-инфраструктуры и владельцам публичных/внутренних репозиториев. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Workflow выполняется на runner и может читать рабочую директорию, переменные окружения и доступные файлы. Публичный репозиторий принимает изменения от внешних авторов, поэтому self-hosted runner с доступом к production-сети или долгоживущими секретами создаёт опасную границу доверия. Очистка workspace не заменяет изоляцию, если вредоносный процесс изменил хост.
Затронутые версии
Руководство относится к self-hosted runners GitHub Actions, включая постоянные и ephemeral runners. Риск зависит от видимости репозитория, правил запуска, сетевого доступа, очистки рабочей директории и полномочий runner machine.
Исправленные версии
Универсальной исправленной версии нет. Для недоверенных pull request используйте GitHub-hosted runners или изолированные ephemeral runners с минимальной сетью и доступом; удаляйте runner после выполнения и не храните на нём постоянные секреты.
Что сделать
- 1Инвентаризируйте runners, labels, репозитории, группы, сетевые маршруты, пользователи и credentials на каждой машине. Отделите runner для доверенного deployment от runner для сборок.
- 2Не направляйте workflow из публичных репозиториев и непроверенных fork на постоянный runner. Проверьте события pull_request_target и ручные approvals.
- 3Используйте ephemeral runner или одноразовую VM/контейнер с минимальным образом, сетью и filesystem permissions. Не монтируйте Docker socket и production credentials без отдельного обоснования.
- 4Храните секреты в GitHub Secrets/environments и выдавайте их только нужной job после approval. Для облака используйте OIDC с ограниченной trust policy.
- 5Закрепляйте actions, проверяйте сторонние скрипты и ограничивайте permissions GITHUB_TOKEN. Не принимайте пользовательский ввод в shell без безопасного quoting.
- 6Протестируйте сборку на изолированном runner и проверьте, что после job удаляются workspace, временные файлы и credentials. Не используйте production runner для отладки недоверенного workflow.
- 7При подозрении на выполнение чужого кода остановите runner, отзовите его credentials и изучите host, workflow logs и сетевые события до повторного подключения.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.