Em 19 de março de 2026, pipelines CI/CD em todo o mundo começaram a executar código que não deveriam. O Trivy — o scanner de vulnerabilidades mais usado em workflows GitHub Actions, com mais de 30 mil stars no GitHub — estava infectado com um infostealer. Não era um bug acidental. Era um ataque planejado, executado por um grupo chamado TeamPCP, que usou a própria ferramenta de segurança como vetor de entrada.

O episódio não ficou isolado. Quatro dias depois, as credenciais coletadas do ambiente do Trivy foram usadas para comprometer a GitHub Action da Checkmarx. O mesmo grupo também atingiu o KICS e o LiteLLM. Quando um supply chain attack funciona, ele se expande.

O que aconteceu: o ataque do TeamPCP ao Trivy

O TeamPCP não começou pelo Trivy diretamente. Em fevereiro de 2026, o grupo identificou uma misconfiguration no ambiente de GitHub Actions do projeto que vazava um token de acesso privilegiado. Com o token, esperaram o momento certo.

Em 19 de março, às 17:43 UTC, o payload foi ativado. Código malicioso foi injetado no arquivo entrypoint.sh do aquasecurity/trivy-action e do aquasecurity/setup-trivy. Em menos de quatro horas, 76 das 77 tags de versão do trivy-action foram reescritas com o código infectado.

As janelas de comprometimento confirmadas pela Aqua Security:

  • trivy binário v0.69.4: das 18:22 às 21:42 UTC em 19 de março
  • trivy-action v0.69.4: das 17:43 UTC em 19 de março até as 05:40 UTC em 20 de março
  • setup-trivy: das 17:43 às 21:44 UTC em 19 de março
  • Imagens no DockerHub v0.69.5 e v0.69.6: em 22 de março

A Aqua Security publicou o GitHub Advisory GHSA-69fq-xp46-6x23, gerando a CVE-2026-33634. A CISA adicionou a vulnerabilidade ao catálogo de exploits ativos na mesma semana.

Como a cadeia de exploração funcionou

O infostealer injetado no entrypoint.sh era funcionalmente normal: executava o Trivy, produzia resultados de scan, não levantava alertas. O que acontecia em paralelo era invisível nos logs.

O payload vasculhava a memória do processo Runner.Worker coletando:

  • GitHub Personal Access Tokens (PATs) disponíveis no ambiente
  • Tokens de autenticação de cloud (AWS, GCP, Azure)
  • Chaves SSH configuradas no runner
  • Variáveis de ambiente de qualquer secret do repositório

A exfiltração usava domínios com typosquats para contornar filtros baseados em padrões. Não havia indicação visível de comprometimento. Os pipelines funcionavam normalmente enquanto credenciais eram coletadas.

O detalhe técnico mais preocupante: a ferramenta faz o que é esperada para fazer. O ataque roda em paralelo ao scan legítimo, sem interferir nos resultados. Times que monitoram apenas falhas e anomalias de output não teriam como detectar.

Os outros alvos: Checkmarx, KICS e LiteLLM

Com as credenciais do Trivy em mãos, o TeamPCP expandiu a campanha. Aproximadamente quatro dias após o comprometimento inicial, a GitHub Action da Checkmarx AST foi infectada com o mesmo mecanismo. O KICS, ferramenta de análise estática de infraestrutura como código mantida pela Checkmarx, também foi atingido na mesma janela. O LiteLLM, proxy para APIs de LLMs com ampla adoção em pipelines de AI, completou a lista de alvos confirmados.

A escolha não é aleatória. Ferramentas de segurança e DevOps têm, por definição, acesso ao ambiente de execução mais privilegiado do pipeline. Times que usam o Trivy para escanear containers têm credenciais de cloud configuradas nos workflows. Times que usam o Checkmarx têm acesso de leitura ao código-fonte. São os ativos mais valiosos de um pipeline CI/CD, e as ferramentas que os protegem costumam ter o maior nível de confiança implícita do sistema.

O problema mais amplo: 29 milhões de secrets no GitHub

O ataque do TeamPCP não criou o problema de secrets expostos em pipelines. Explorou um que já existia em escala.

O relatório State of Secrets Sprawl 2026 do GitGuardian, publicado em março, documentou 28,65 milhões de novos secrets hardcoded adicionados a repositórios públicos do GitHub em 2025. Um crescimento de 34% em relação ao ano anterior. O número que me impressiona não é o volume, mas a persistência: uma amostra de credenciais expostas em 2022, reavaliada em janeiro de 2026, ainda mostrava taxa de validade acima de 64%. A maioria dos secrets expostos nunca foi rotacionada.

Tem um dado que a maioria dos times não vê: 32,2% dos repositórios internos contêm pelo menos um secret hardcoded, contra 5,6% dos repositórios públicos. Código interno tem seis vezes mais secrets embutidos que código público. E é exatamente esse código que roda nos pipelines CI/CD onde o TeamPCP fez seu trabalho.

Para times com stack de AI: a situação é mais aguda. Credenciais de serviços de IA expostas cresceram 81% em 2025, chegando a 1,27 milhão de secrets vazados. Código gerado com assistência de IA apresenta taxa de vazamento aproximadamente duas vezes maior que a média do GitHub. O relatório ainda aponta que 28% dos incidentes de secrets sprawl não têm origem em repositórios: vêm de ferramentas de colaboração como Slack, Jira e Confluence.

Como verificar se seu pipeline foi afetado

Se qualquer workflow usou o Trivy, a Checkmarx AST Action ou o setup-trivy nas janelas de comprometimento acima, considere o ambiente afetado até prova em contrário.

Verificar versões em uso

As versões seguras confirmadas pela Aqua Security são:

  • trivy binário: v0.69.3 ou anterior
  • trivy-action: v0.35.0
  • setup-trivy: v0.2.6

Se seus workflows referenciam @v0.69.4, @latest ou qualquer tag sem SHA fixado, e os jobs foram executados entre 19 e 22 de março de 2026, todos os secrets acessíveis nesses runs devem ser considerados expostos.

Rotacionar credenciais

A rotação deve incluir todos os secrets que estavam disponíveis nos workflows afetados:

  • GitHub PATs configurados como secrets do repositório ou da organização
  • Credenciais de cloud (AWS access keys, GCP service accounts, Azure service principals)
  • Chaves SSH no ambiente de execução
  • Tokens de APIs de terceiros configurados nos pipelines

Rotacionar sem investigar é insuficiente. Se os tokens já foram usados em chamadas fora do padrão habitual, a investigação precisa mapear o que foi acessado antes de encerrar o incidente.

Revisar logs de acesso

Antes de invalidar credenciais, verifique logs de uso nas plataformas de cloud: AWS CloudTrail, GCP Audit Logs, Azure Activity Log. Credenciais roubadas podem ter sido usadas para criar novos acessos persistentes. Rotacionar o token original sem revogar acessos derivados deixa a janela aberta.

Proteções que funcionam de verdade

O ataque do TeamPCP expõe uma fragilidade estrutural dos workflows GitHub Actions: tags de versão são mutáveis. Qualquer pessoa com permissão de escrita no repositório pode reescrever uma tag para apontar para um commit diferente, que foi exatamente o que aconteceu aqui.

A proteção mais efetiva é pinagem por commit SHA:

# Com tag — mutável, pode ser reescrita
- uses: aquasecurity/trivy-action@v0.35.0

# Com SHA — imutável, auditável (substituir pelo SHA real do commit desejado)
- uses: aquasecurity/trivy-action@7c2807ff0bf84e86c00c9cd4f6264a1fd593f5b2

O SHA aponta para um commit específico no histórico do Git. Se o repositório upstream for comprometido, o SHA que você fixou continua apontando para o código que foi auditado. Ferramentas como Dependabot e Renovate podem automatizar a atualização controlada desses SHAs.

Além da pinagem, configurações de permissão fazem diferença concreta. Um workflow com GITHUB_TOKEN de permissões mínimas limita o que um payload malicioso pode acessar mesmo se executado:

permissions:
  contents: read
  security-events: write  # apenas o necessário para o job

Combinado com tokens OIDC para autenticação em cloud (em vez de secrets de longa duração), o valor das credenciais coletadas cai substancialmente. Tokens OIDC são de curta duração e escopados por workflow.

O GitHub anunciou em seu roadmap de segurança 2026 funcionalidades de bloqueio determinístico de dependências com SHA no YAML do workflow e controles de egress em nível de infraestrutura, com public preview previsto para o segundo semestre. Até lá, pinagem por SHA e permissões mínimas são as proteções disponíveis agora.

Conclusão

O ataque do TeamPCP funciona porque o modelo de confiança implícita em actions de terceiros nunca foi questionado na escala necessária. Quando você adiciona uses: aquasecurity/trivy-action@v0.35.0 a um workflow, está executando código externo com acesso irrestrito ao ambiente de CI/CD. Por anos, isso foi aceitável porque as ferramentas eram confiáveis.

A confiança na identidade de uma ferramenta não é a mesma coisa que confiança na imutabilidade do código que ela executa. Tags mudam. Repositórios são comprometidos. O SHA é o único mecanismo que oferece garantia verificável.

O inventário de actions que seu time usa, as versões fixadas, as permissões concedidas e os secrets acessíveis nos workflows: esse é o trabalho que transforma segurança de CI/CD de princípio em prática.

Referências pesquisadas nesta publicação