17 сентября 2026 года GitHub перевёл workflow execution protections для GitHub Actions в статус general availability. Механизм позволяет контролировать не только права внутри уже запущенного workflow, но и сам факт его запуска.

Для CI это важное изменение. Чем больше в репозитории автоматизации, секретов и действий с инфраструктурой, тем важнее заранее определить кто и каким событием вообще может запустить чувствительный сценарий.

Что теперь можно ограничивать

Execution protections работают с двумя основными типами правил. Actor rules определяют кто может инициировать запуск. Event rules определяют какие события разрешено использовать для старта workflow.

В стабильной версии GitHub добавил возможность применять правило к конкретному файлу workflow. Например deploy workflow можно закрыть для ограниченной группы участников, не затрагивая обычные проверки кода.

Также появились Insights. Они показывают как правила срабатывают на реальных запусках и помогают увидеть последствия до жёсткого включения ограничений.

Evaluate mode снижает риск сломать CI

Новые ограничения безопасности легко сделать слишком строгими. Поэтому полезен evaluate mode. В этом режиме правило оценивает запуски, но пока не блокирует их.

Команда может посмотреть какие workflow попали бы под ограничение, скорректировать политику и только после этого включить enforcement. Для рабочего проекта это безопаснее, чем менять правила доступа вслепую и узнавать о проблеме во время очередного деплоя.

Правила можно управлять через REST API

GitHub добавил REST API для управления execution protections на уровне enterprise, organization и repository. Это позволяет хранить политику как часть инфраструктурного процесса и одинаково применять её к большому числу репозиториев.

Для команд с несколькими проектами это особенно полезно. Вместо ручной настройки каждого репозитория можно централизованно задавать правила и контролировать их состояние.

Отдельное внимание к pull_request_target

GitHub отдельно усиливает защиту сценариев с событием pull_request_target. Такой workflow выполняется в контексте базового репозитория и может иметь доступ к секретам. Если внутри него небезопасно выполняется код из внешнего fork, появляется риск утечки секретов и компрометации CI.

Для публичных репозиториев без собственной подходящей политики GitHub вводит правило по умолчанию, которое ограничивает pull_request_target. Сначала оно работает в evaluate mode. Автоматическое применение для затронутых репозиториев запланировано на 2 ноября 2026 года.

Что стоит проверить в своих workflow

Если GitHub Actions используется для деплоя, публикации пакетов, работы с API или инфраструктурой, стоит посмотреть какие события запускают критичные workflow и действительно ли каждому участнику нужен такой доступ.

Особенно внимательно стоит проверить сценарии с внешними pull request, секретами, production окружением и автоматической публикацией. Execution protections не заменяют минимальные permissions для GITHUB_TOKEN и безопасную работу с secrets, но добавляют ещё один полезный барьер до старта workflow.

Если нужно проверить GitHub Actions, права, секреты и логику деплоя в рабочем проекте, можно написать мне. Также полезно посмотреть материалы про контроль версий GitHub Actions runners и доступ Dependabot к GitHub Packages без PAT.