GitHub сделал общедоступными средства защиты выполнения рабочих процессов в GitHub Actions — системе для команд разработки, запускающих рабочие процессы CI и развёртывания в репозиториях. Правила позволяют ограничивать запуск рабочих процессов по пользователям и событиям.Что изменилосьМеханизм доступен на уровне GitHub Enterprise, организаций и отдельных репозиториев. В GA-версии правила можно привязывать к конкретным файлам рабочих процессов. Например, разрешить запуск рабочего процесса deploy.yml только выбранной команде, не ограничивая обычные CI-задачи.GitHub также добавил раздел Insights для проверки срабатываний и REST API для создания, чтения, изменения и удаления правил. Режим evaluate позволяет заранее увидеть, какие запуски будут заблокированы, не применяя ограничения.Новые настройки по умолчаниюДля публичных репозиториев без подходящей политики событий GitHub вводит правило, которое отключает pull_request_target. Сначала оно работает в режиме evaluate. На приватные и внутренние репозитории изменение не распространяется.Событие pull_request_target выполняется в контексте основного репозитория и может получать доступ к его секретам. Если workflow запускает недоверенный код из форка, злоумышленник способен изменить процесс сборки и извлечь секреты.2 ноября 2026 года GitHub начнёт принудительно применять правило в затронутых репозиториях, которые до GA использовали стандартную политику pull_request_target. Владельцам таких репозиториев стоит проверить результаты в Insights, затем оставить блокировку или явно разрешить событие в политике. Отдельные рабочие процессы можно добавить в список разрешённых.ИсточникиWorkflow execution protections in GitHub Actions generally available - GitHub Changelog