GitHub Actions ganha proteção para workflows perigosos

Segurança · "Loop"

O GitHub tornou disponíveis de forma geral as proteções de execução para Actions. Organizações podem permitir ou bloquear workflows por ator, evento e arquivo, primeiro em modo de avaliação e depois com enforcement. A mudança mais urgente está em repositórios públicos: uma regra para pull_request_target começa a bloquear cenários perigosos em 2 de novembro de 2026.

Por que pull_request_target exige cuidado

O evento pull_request_target executa no contexto do repositório base. Isso permite comentar, rotular ou gerenciar um PR vindo de fork com permissões que um pull_request comum não receberia. O risco aparece quando o workflow faz checkout e executa o código não confiável da branch proposta.

# Combinação perigosa: contexto privilegiado + código do fork
on: pull_request_target

steps:
  - uses: actions/checkout@v4
    with:
      ref: ${{ github.event.pull_request.head.sha }}
  - run: npm install
  - run: npm test

Scripts de instalação e testes do atacante podem alcançar token com escrita, secrets ou caches. A recomendação é usar pull_request para construir e testar código do PR. Reserve pull_request_target para operações sobre metadados e não execute conteúdo controlado pelo contribuidor.

O que as novas políticas controlam

  • Atores autorizados ou bloqueados.
  • Eventos que podem disparar execução.
  • Arquivos de workflow específicos atingidos pela regra.
  • Modo de avaliação, para observar violações sem interromper pipelines.
  • Insights e REST API para administrar e acompanhar a política.

O padrão anunciado para repositórios públicos mira pull_request_target. A regra já pode aparecer em avaliação e será imposta na data prevista. Repositórios privados e internos não entram nessa regra padrão, embora possam adotar políticas próprias.

Como revisar antes do enforcement

  • Pesquise pull_request_target em .github/workflows.
  • Localize checkout da ref ou SHA do PR, builds, testes e instalação de dependências.
  • Inspecione permissions e reduza o GITHUB_TOKEN ao mínimo.
  • Separe o workflow não confiável do workflow que comenta ou publica resultados.
  • Revise caches, artifacts e workflow_run para evitar promoção de conteúdo adulterado.

A regra de plataforma é uma última barreira, não uma prova de segurança do YAML. Workflows podem continuar perigosos por injeção em shell, actions de terceiros não fixadas ou permissões excessivas. Use o modo de avaliação para encontrar impacto, mas corrija a arquitetura antes de simplesmente criar exceções.

A oportunidade é transformar costume em política

Até aqui, evitar a combinação perigosa dependia muito de review especializado. Com proteções de execução, a organização consegue codificar o limite e enxergar violações centralmente. Isso reduz a chance de um novo workflow repetir um erro já conhecido.

O prazo até novembro deve ser usado para separar automação de contribuição e automação privilegiada. Se um workflow precisa dos dois contextos, provavelmente ele precisa virar dois workflows com uma passagem de dados explícita e validada.

Fontes

Leia também