O GitHub anunciou em 18 de junho, no changelog oficial, o preview público de workflow execution protections no GitHub Actions. O recurso permite definir uma lista de quem pode disparar workflows e quais eventos estão autorizados, em níveis de enterprise, organização e repositório. A proposta é tirar parte do controle de segurança do arquivo YAML e colocá-lo em política central avaliável antes da execução.
Segundo o GitHub Changelog, antes dessa proteção um workflow rodava com base no arquivo presente no commit que disparou o evento. Em certos cenários, alguém com acesso ao repositório poderia alterar o YAML para executar código malicioso. Com as novas proteções, o Actions avalia ator e evento antes do run, impedindo que uma identidade ou gatilho não autorizado chegue à execução.
A documentação do GitHub explica que o recurso usa o framework de rulesets. Isso permite aplicar regras amplas por organização e escopar por propriedades customizadas de repositório. Também há modo de avaliação, no qual a regra mostra o que bloquearia sem interromper workflows existentes. Para ambientes grandes, esse modo é a diferença entre governança e quebra operacional.
Ator e evento entram na política
As primeiras regras disponíveis são de ator e evento. Regras de ator controlam quem pode iniciar workflows: usuários, papéis de repositório, GitHub Apps, Copilot e Dependabot aparecem como exemplos. Regras de evento controlam gatilhos como push, pull_request, pull_request_target e workflow_dispatch.
Essa separação resolve um problema comum. Dar permissão de escrita a alguém não deveria significar automaticamente dar permissão para rodar qualquer workflow com qualquer segredo ou permissão disponível no pipeline. Um colaborador pode contribuir código; um mantenedor pode decidir quando CI sensível roda; um aplicativo pode disparar automações restritas; e Dependabot pode seguir política própria.
O risco do pull_request_target
O GitHub cita ataques como poisoned pipeline execution, abuso de workflow_dispatch e execução por atores de baixa confiança. O caso de pull_request_target é especialmente delicado porque esse evento pode rodar com contexto do repositório base e expor permissões se mal configurado. Uma regra central que limita esse gatilho reduz a chance de cada repositório resolver o problema de forma diferente.
No dia a dia, isso complementa revisão de YAML, permissões mínimas e segredos bem escopados. Nenhuma política substitui revisar o que o workflow faz, mas impedir que qualquer ator ou evento dispare a execução já corta parte importante da superfície de ataque.
Governança sem travar o delivery
O valor do recurso aparece mais em organizações com muitos repositórios. Em vez de pedir que cada time copie o mesmo bloco de configuração, a plataforma aplica uma política comum. Repositórios críticos podem ter regra mais rígida; projetos experimentais podem começar em avaliação; e exceções ficam visíveis no mesmo modelo de ruleset.
Essa abordagem conversa com o post sobre dependência operacional do GitHub. Quando uma plataforma central sustenta CI, release, revisão e automação, a configuração dela deixa de ser detalhe local. Controle de execução precisa fazer parte do desenho de segurança da organização.
Como adotar
O primeiro passo é listar quais eventos realmente precisam rodar em cada classe de repositório. Depois, separar atores humanos, bots, GitHub Apps e automações internas. Em seguida, aplicar rulesets em modo de avaliação e revisar quais runs teriam sido bloqueados. Só depois faz sentido ativar a regra.
Também vale revisar workflows chamados manualmente. workflow_dispatch é útil para manutenção e release, mas pode virar atalho perigoso se qualquer pessoa com escrita disparar jobs com segredo, deploy ou token privilegiado.
Uma adoção bem feita também precisa mapear exceções. Repositórios de release, infraestrutura e segurança tendem a exigir regras mais rígidas que bibliotecas internas ou protótipos. Sem esse mapeamento, a organização corre o risco de criar uma política ampla demais, gerar bloqueios legítimos e depois desativar a proteção inteira por desgaste operacional.
No GitHub Actions, segurança de execução não deve depender só da disciplina de cada arquivo YAML. A nova camada de políticas permite tratar CI como superfície governada: ator certo, evento certo, permissão certa e rollout testado antes de bloquear produção.
