30/3/2026

Como práticas seguras de build nos protegeram do ataque de supply chain no Trivy

Recentemente, surgiram relatos de um ataque de supply chain envolvendo releases comprometidas do scanner de vulnerabilidades Trivy e componentes relacionados, incluindo seus GitHub Actions. Como o Trivy está integrado aos nossos workflows principais de desenvolvimento, iniciamos imediatamente uma investigação interna para avaliar qualquer possível impacto em nossa infraestrutura.

Este post apresenta nossas conclusões e, mais importante, os controles de segurança específicos que garantiram que nossos repositórios não fossem afetados.

‍

O que aconteceu

Em 19 de março de 2026, um agente malicioso identificado como “TeamPCP” comprometeu o pipeline de release de vários projetos da Aqua Security. Explorando uma vulnerabilidade de configuração previamente identificada, os atacantes realizaram um force-push de código malicioso para a tag v0.69.4 do binário principal do Trivy e para praticamente todas as tags de versão do aquasecurity/trivy-action.

O payload malicioso foi projetado para exfiltrar dados sensíveis de CI/CD, incluindo credenciais de cloud providers, chaves SSH e tokens de Kubernetes, enviando-os para um domínio com typosquatting (scan.aquasecurtiy[.]org). Em alguns casos, o malware tentou criar um repositório de fallback chamado tpcp-docs dentro da organização GitHub da vítima para armazenar os segredos roubados.

Por que isso era relevante para nós

Trivy é utilizado em diversos repositórios da nossa organização como parte dos pipelines de CI/CD. Ele é uma das várias ferramentas usadas para detectar e corrigir vulnerabilidades de forma proativa no nosso código. Qualquer comprometimento em uma ferramenta amplamente utilizada no desenvolvimento exige revisão imediata.

Assim que surgiram relatos confiáveis, tratamos a situação como um possível incidente e iniciamos uma investigação interna.

Nossa investigação

Assim que o incidente foi reportado, auditamos os logs de execução de CI/CD para identificar quais versões do binário do Trivy foram efetivamente utilizadas pelos nossos runners.

Nossa investigação confirmou que, durante a janela do ataque, nossos pipelines executaram o Trivy v0.69.2 (versão confirmada como segura). Essa versão foi lançada antes do comprometimento.

Diversos fatores contribuíram para nossa proteção:

GitHub Action Pinning (Commit SHA): Ao referenciar o aquasecurity/trivy-action por meio de seu commit SHA único, garantimos que a lógica da automação não fosse alterada.
Version Consistency: Nosso ambiente permaneceu naturalmente na versão v0.69.2, evitando a versão maliciosa v0.69.4 que foi temporariamente publicada.

Conclusão: nossos repositórios não foram afetados

Após concluir a análise, confirmamos que nossos repositórios não foram impactados pelo ataque de supply chain do Trivy.

Diversos controles já existentes tiveram papel determinante.

Por que estávamos protegidos

1) GitHub Actions fixadas por commit SHAs

Diferente de version tags mutáveis (como v0.69.4), que podem ser redirecionadas para outro commit por qualquer pessoa com acesso ao repositório, commit SHAs são imutáveis.

Como nossos pipelines referenciam hashes específicos, o force-push malicioso realizado pelos atacantes não afetou nossos runners. Nossos sistemas continuaram executando exatamente o código confiável previamente definido.

2) Uso de binaries confiáveis previamente em cache

Nossos sistemas mantinham uma versão segura e previamente validada do binário do Trivy.

Como resultado, nossos pipelines não baixaram versões comprometidas durante a janela do ataque.

3) Timing de atualização

Atualizamos o Trivy aproximadamente nove dias antes do ataque (10 de março de 2026), reduzindo ainda mais a probabilidade de exposição às versões afetadas.

4) Arquitetura de CI/CD

Embora não tenha sido determinante neste caso, a Tenchi optou por executar apenas CI (testes) via GitHub Actions.

Toda a lógica de CD (deployment) é executada dentro do nosso próprio ambiente AWS, justamente para minimizar a quantidade de código externo com acesso a credenciais de staging e produção.

Ou seja, mesmo que tivéssemos executado a versão maliciosa do Trivy, nenhum segredo presente no GitHub Actions teria levado ao comprometimento de dados de clientes.

Esse modelo já havia sido discutido anteriormente no contexto do incidente de supply chain envolvendo o tj-actions/changed-files, abordado em nosso podcast.

Monitoramento contínuo

Embora nenhum impacto tenha sido identificado, seguimos monitorando o desenrolar desse incidente e revisando nossos controles de segurança como parte das práticas padrão.

Mais detalhes sobre o ataque

‍