GitHub endurece actions/checkout para conter pwn requests e proteger a cadeia de fornecimento

O GitHub decidiu endurecer uma das vias de ataque mais recorrentes contra a cadeia de fornecimento de software: a partir de 18 de junho de 2026 a ação oficial actions/checkout deixará por defeito aceitar padrões comuns de "pwn requests" que exploram o gatilho pull_ request_target para executar código malicioso com privilégios do repositório base. A medida será primeiramente aplicada na versão mais recente (v7) e, segundo anunciou a empresa, será retroportada às principais versões com suporte em 16 de julho de 2026.

A modificação técnica chave é que Actions/checkout v7 recusa-se a trazer o código do pull request quando este vem de um fork e estão preenchidas certas condições — por exemplo, quando o parâmetro repousaitory aponta para o fork e o ref corresponde a refs/pull/.../head ou refs/pull/.../merge— exceto que o autor do fluxo opte explicitamente por desativar a proteção usando allow-unsafe-pr-checkout=true. A ação também aplica esta restrição em execuções de workflow_run que estejam relacionadas a eventos de tipo pull_request.

Entender por que isso importa requer lembrar como funciona pull_request_target: esse evento é executado no contexto do ramo por defeito do repositório base e, por design, carrega um GITHUB_TOKEN com permissões de leitura e escrita e pode acessar segredos. Se nesse fluxo for baixado e executa o código enviado por um contribuinte de um fork, um atacante pode introduzir scripts que roben tokens, envenenen caches ou abusen de privilégios para publicar mudanças maliciosos. Ataques recentes que exploraram vetores similares afetaram projetos e pacotes sensíveis, incluindo incidentes que comprometeram ecossistemas como Nx e pacotes populares de outras organizações.

A iniciativa do GitHub reduz significativamente o risco do padrão mais comum de pwn requests, mas não é uma solução completa. A nova proteção só intervém quando o checkout é feito mediante actions/checkout: nada impede um fluxo executar git, usar a CLI do GitHub ou qualquer outra ação externa para obter código não confiável, nem bloqueia outros eventos que podem ser usados de forma abusiva. Por conseguinte, ainda existem vectores de risco que requerem revisão humana e controlos adicionais.

Para equipas e responsáveis pela segurança, esta notícia deve traduzir-se em acções concretas e imediatas. O primeiro é atualizar os fluxos que utilizem actions/checkout e testar a versão v7; rever os workflows que dependem de pull_request_target e perguntar se realmente precisam ser executados com os segredos ou com permissões elevadas. Em muitos casos, a alternativa segura é substituir o pull_ request_target por pull_ request Quando não são necessários privilégios do repositório de base, ou limitar rigorosamente as permissões do GITHUB_TOKEN através da chave permissions no workflow.

Além de mudar triggers e versões, convém adotar práticas operacionais: exigir revisões humanas antes de serem executadas workflows com privilégios sobre PRs de forks, evitar o consumo direto de segredos em jobs que processam entradas externas e não habilitar allow-unsafe-pr-checkout salvo em circunstâncias muito justificadas e com controles compensatórios. Também é aconselhável consolidar acções reutilizáveis que residam apenas no repositório de base e aplicar políticas de protecção de ramos e revisões para evitar execuções automáticas sem supervisão.

Do ponto de vista da governança da cadeia de abastecimento, esta melhoria é bem-vinda porque atua como um guardrail que previne erros comuns de configuração. No entanto, as equipes devem ver isso como parte de uma abordagem mais ampla que inclua auditorias de workflows, redução da superfície de privilégios e uso de mecanismos modernos como OIDC para implantaçãos (que minimizam a dependência de segredos estáticos).

Se você quer rever a implementação ou atualizar seus fluxos, consulte o repositório oficial da ação no GitHub para seguir os lançamentos: actions/checkout no GitHub. Para entender as implicações do evento que provoca as maiores preocupações, a documentação oficial sobre pull_request_target explica por que este trigger precisa de cautela: documentação do pull_ request_target. Também é útil ler os guias de endurecimento do GitHub Actions para aplicar controles adicionais: Security hardening for GitHub Actions.

Em suma, a atualização de actions/checkout é um passo positivo que bloqueia o vetor mais explorado de pwn requests, mas não substitui a necessidade de políticas operacionais e técnicas mais amplas: auditar workflows, minimizar permissões, evitar executar código não revisado em eventos privilegiados e atualizar ações regularmente Devem ser parte da rotina para proteger a cadeia de abastecimento.