O ataque que comprometeu 23.000 repositórios
Para entender a urgência, é útil olhar para o que aconteceu.
Em 2025, o pacote tj-actions/changed-files — uma action amplamente usada no GitHub Actions — foi comprometido em um ataque de supply chain. Os atacantes roubaram um token de acesso pessoal, redirecionaram todas as tags de versão para código malicioso, e começaram a exfiltrar segredos de CI/CD (incluindo credenciais da Coinbase) através dos logs de workflow.
Mais de 23.000 repositórios foram afetados. Outros ataques similares atingiram os pacotes Nx e trivy-action no mesmo período.
O padrão é sempre o mesmo: os atacantes não precisam invadir o código da aplicação. Eles invadem o pipeline que constrói e implanta o código e, de lá, ganham acesso a credenciais que dão entrada em tudo.
O problema estrutural que esses ataques exploram
O GitHub articulou o problema claramente no post do roadmap: “vulnerabilidades permitem execução de código não confiável, workflows maliciosos rodam sem observabilidade ou controle, dependências comprometidas se espalham por milhares de repositórios, credenciais com excesso de permissão são exfiltradas via acesso de rede irrestrito.”
A raiz do problema está em como o GitHub Actions foi projetado. Dependências são resolvidas em runtime usando referências mutáveis, tags e branches. Quando você escreve uses: actions/checkout@v4, está dizendo “use o que quer que a tag v4 aponte agora”. O problema é que essa tag pode mudar. E se um atacante comprometer o repositório da action e reapontar a tag para código malicioso, todos os pipelines que usam essa referência executam o código malicioso, sem nenhuma mudança visível nas suas configurações.
É como se você dependesse de um fornecedor externo em um contrato que diz “entregue o produto que você chamar de versão 3”, sem especificar o conteúdo. Se o fornecedor mudar o produto sem avisar, você recebe outra coisa.
O que o roadmap de 2026 do GitHub Actions endereça
Em março de 2026, o GitHub publicou o roadmap de segurança para Actions, descrito internamente como a maior evolução de segurança da plataforma desde seu lançamento. As mudanças se organizam em cinco áreas:
1. Dependency locking (bloqueio de dependências)
Inspirado no modelo go.mod + go.sum do Go, o GitHub vai introduzir uma seção dependencies: nos arquivos de workflow que permite travar dependências diretas e transitivas a SHAs de commit específicos. Assim, em vez de depender de uma tag mutável, você especifica um hash exato e a plataforma verifica antes de executar.
Isso é, na prática, o que impediria o ataque ao tj-actions de funcionar: mesmo que a tag fosse redirecionada, o workflow só executaria o código com o SHA que você aprovou. Mudanças de dependência aparecem como diferenças visíveis em pull requests.
2. Scoped secrets (segredos com escopo)
Hoje, se um workflow tem acesso a um segredo, todos os jobs do workflow podem lê-lo. Com a nova abordagem, credenciais poderão ser vinculadas a contextos específicos de execução, repositórios, jobs, runners específicos. O princípio de privilégio mínimo passa a ser aplicável a cada credencial individualmente.
3. Policy controls (controles de política)
Times de segurança e plataforma ganharão mecanismos centralizados para definir o que pode e o que não pode acontecer em workflows: quais actions são permitidas, quais runners podem ser usados, quais padrões de execução são bloqueados por padrão. Isso move a segurança de CI/CD de “cada workflow author sendo cuidadoso” para “a plataforma impõe comportamento seguro por padrão”.
4. Actions Data Stream (observabilidade de CI/CD)
Talvez a mudança mais relevante para times de segurança e operações. O Actions Data Stream entrega telemetria de execução em tempo real para sistemas externos, atualmente Amazon S3 e Azure Event Hub. Com isso, é possível monitorar comportamento de CI/CD de forma contínua: workflows que de repente fazem requisições para domínios desconhecidos, jobs que acessam segredos que nunca acessaram antes, runners com padrões de tráfego anômalos.
CI/CD observável como qualquer sistema de produção. Não mais investigação post-mortem depois de um incidente, mas detecção em tempo real.
5. Egress firewall nativo para runners
GitHub-hosted runners atualmente têm acesso de rede de saída irrestrito. Isso é conveniente e exatamente o que permite que código comprometido exfiltre segredos. O firewall de egress nativo permitirá definir políticas precisas: domínios permitidos, ranges de IP, métodos HTTP, requisitos de TLS. Um modo de monitoramento permite que times observem padrões antes de ativar enforcement.
Por que isso é tema de negócio, não só de engenharia
Há um argumento que profissionais de segurança repetem há anos, mas que os ataques de supply chain estão tornando tangível: o pipeline de CI/CD não é uma ferramenta de desenvolvimento. É uma infraestrutura crítica.
Quando um pipeline é comprometido, o atacante não ganha só acesso a código. Ganha acesso a credenciais de cloud, tokens de publicação em registries de pacotes, chaves de acesso a bancos de dados de produção, e à cadeia de confiança por trás do software que seus clientes usam.
Para empresas que dependem de software de terceiros, que é praticamente toda empresa em 2026, um ataque de supply chain em uma biblioteca que você usa pode comprometer seu ambiente de produção sem que nenhum atacante tenha tocado em um único arquivo seu. A analogia com supply chains físicas é direta: se seu fornecedor de matéria-prima for comprometido, seu produto final é comprometido.
Isso tem implicações que vão além de engenharia:
Para produto: produtos que dependem de pipelines CI/CD para releases rápidos precisam equilibrar velocidade com segurança de dependências. Actions não pinadas a SHAs específicos são um risco de disponibilidade, não só de segurança.
Para compliance: regulamentações como SOC 2, ISO 27001 e setoriais como DORA para serviços financeiros estão incluindo explicitamente segurança de supply chain de software em seus escopos. Times de compliance precisam entender o que está rodando nos pipelines.
Para gestão de risco: o impacto de um ataque de supply chain pode ser comparável a um breach direto, mas com muito menos controle sobre a superfície afetada. É um risco que precisa estar no mapa de riscos corporativos.
O que times técnicos podem fazer agora, antes do roadmap chegar
O roadmap do GitHub tem timeline de 3 a 9 meses para a maioria das features chegarem ao GA. Mas existem ações que reduzem risco hoje:
Pinar actions a SHAs de commit. Em vez de uses: actions/checkout@v4, use uses: actions/checkout@b4ff665f46336ab88eb53be808477a3936bae11. Um comando de grep identifica todas as referências não-pinadas nos seus workflows.
Habilitar o Dependabot para Actions. Ele pode alertar quando dependências de Action têm vulnerabilidades conhecidas.
Revisar permissões de segredos. Quais workflows têm acesso a quais segredos? Essa visibilidade é o primeiro passo antes da chegada dos scoped secrets.
Monitorar tráfego de saída de runners. Se você usa self-hosted runners, configurar monitoramento de rede no nível do host revela padrões suspeitos.
Conclusão: A mudança cultural que isso exige
O que o roadmap do GitHub representa é uma aceleração de algo que a indústria de segurança já vinha pedindo: tornar o comportamento seguro o padrão, não o resultado de cada time sendo cuidadoso individualmente.
O padrão histórico é que segurança opt-in funciona mal. HTTPS só se tornou ubíquo quando o Let’s Encrypt tornou gratuito e automático. A varredura de containers só se tornou padrão quando foi integrada aos registries. Segurança de supply chain está seguindo o mesmo caminho.
Para empresas que dependem de software, isso não é optativo, é uma questão de quando, não de se.
