GitHub endurece actions/checkout para bloquear pwn requests comuns

GitHub agora bloqueia por padrão o checkout de pull requests de forks em workflows disparados por pull_request_target e workflow_run, fechando uma brecha que permitia código malicioso rodar com permissões elevadas do repositório base. A mudança ataca diretamente o padrão mais usado em ataques de supply chain, quando um atacante envia um PR com scripts maliciosos, o workflow faz checkout automático e executa o código com o GITHUB_TOKEN, secrets e cache do repositório original. Isso foi explorado em campanhas como s1ngularity contra Nx e PostHog, onde o acesso aos segredos permitiu a comprometimento de pacotes distribuídos para milhares de usuários.

A nova regra do actions/checkout v7 recusa automaticamente refs como refs/pull/number/head ou commits de fork, a menos que o mantenedor ative explicitamente allow-unsafe-pr-checkout: true. O foco é evitar que workflows privilegiados executem código não revisado sem consentimento consciente. Mas o risco não some: workflows que usam git clone manual, CLI ou outros triggers como issue_comment ainda estão expostos. A proteção é uma barreira, não uma solução completa.

Essa mudança força equipes a reconsiderar o uso de pull_request_target, um gatilho criado para automação de metadados, não para execução de código externo. Muitos ainda o usam por conveniência, mas a nova política torna explícito o custo de segurança: se você precisa de permissões de escrita ou acesso a secrets, o código que roda deve ser confiável desde o início. Empresas que não revisam workflows de terceiros ou que aceitam contribuições de forks sem validação ficam vulneráveis mesmo com a atualização. A mudança não corrige a cultura de confiança cega, mas impõe um custo operacional que obriga a pensar antes de agir.