Padrão de ataques a ferramentas de segurança

O incidente com o Trivy não surgiu do nada. Desde 2020, observa-se um padrão crescente de ataques a fornecedores de software de segurança e ferramentas DevSecOps:

• 2020, SolarWinds Orion: Malware SUNBURST injetado em atualização legítima, comprometendo 18.000+ organizações incluindo agências governamentais dos EUA.
• 2021, Kaseya VSA: REvil comprometeu a plataforma de gestão remota usada por MSPs, afetando 1.500+ clientes em cascata.
• 2023, 3CX Desktop App: Trojanização do cliente VoIP, distribuído através do canal oficial de atualização assinado.
• 2024, XZ Utils (CVE-2024-3094): Backdoor inserida em biblioteca de compressão usada por múltiplas distribuições Linux, descoberta por acaso por engenheiro da Microsoft.
• 2026, Trivy: Uma credencial comprometida permitiu publicar uma versão maliciosa (v0.69.4) e reapontar as tags das GitHub Actions trivy-action e setup-trivy para um ladrão de credenciais.

Método do ataque ao Trivy

De acordo com o aviso de segurança da Aqua Security (GHSA-69fq-xp46-6x23) e com as análises da Wiz publicadas entre 19 e 23 de março de 2026, o ataque não passou por um pull request nem por uma vulnerabilidade no código do Trivy:

1. Credencial comprometida: O atacante, que se autodenomina TeamPCP, usou acesso retido de um incidente anterior, iniciado no final de fevereiro de 2026 e não totalmente contido, para atuar com credenciais legítimas do projeto.
2. Commits impostores: Foram feitos commits que falsificavam a identidade de contribuidores legítimos, no repositório do Trivy e no da action actions/checkout.
3. Versão maliciosa v0.69.4: A 19 de março de 2026, a tag v0.69.4 foi publicada e desencadeou uma release com binários maliciosos, distribuídos pelo GitHub Releases (incluindo os pacotes .deb e .rpm), pelo Docker Hub, pelo GHCR e pelo ECR Public. A 22 de março surgiram ainda imagens maliciosas v0.69.5 e v0.69.6 no Docker Hub.
4. Tags das GitHub Actions reapontadas: 76 das 77 tags de versão da action aquasecurity/trivy-action e as 7 tags da setup-trivy foram forçadas para commits maliciosos com um ladrão de credenciais, que lia a memória do processo do runner e recolhia chaves SSH, credenciais de cloud, tokens de Kubernetes e configurações Docker de cada pipeline que referenciasse a action por tag.

O resultado: ferramentas de segurança que verificavam vulnerabilidades nos sistemas de produção tornaram-se elas próprias vetores de comprometimento.

Análise técnica: por que o pinning por tag não basta

Um dos pontos mais relevantes deste incidente é que as tags de versão das GitHub Actions são mutáveis: quem tem credenciais de escrita pode reapontar uma tag existente para outro commit, e todos os pipelines que a referenciam passam a executar o novo código sem qualquer alteração do seu lado. Referenciar uma action por tag confirma apenas o nome da versão, não a integridade do código que é executado.

O que é necessário além da referência por tag

• Pinning por hash de commit: Referenciar as GitHub Actions pelo SHA completo do commit, e não por tag ou branch.
• SBOM (Software Bill of Materials): Inventário completo de todas as dependências e componentes incluídos num artefacto de software, nos formatos SPDX ou CycloneDX.
• Verificação de checksums com pinning: Em vez de latest, usar checksums SHA-256 fixos para cada versão de ferramenta usada em pipelines.
• Sigstore / Cosign: Assinatura criptográfica de imagens de container e binários ligada a identidades verificáveis e a logs de transparência imutáveis.
• SLSA (Supply-chain Levels for Software Artifacts): Framework do Google/OpenSSF que define níveis de maturidade na integridade da cadeia de build.
• Revisão de builds reproducíveis: Capacidade de reconstruir bit-a-bit o artefacto final a partir do código-fonte, permitindo detetar diferenças.

Implicações NIS2 para as entidades abrangidas

O art. 27.º, alínea c), do DL 125/2025 inclui entre as medidas de cibersegurança a "segurança da cadeia de abastecimento, incluindo aspetos de segurança respeitantes às relações entre cada entidade e os respetivos fornecedores ou prestadores de serviços diretos", e o art. 28.º concretiza o que essas medidas devem considerar: as vulnerabilidades específicas de cada fornecedor, a qualidade dos produtos na componente de cibersegurança e as práticas de cibersegurança dos fornecedores, incluindo os seus procedimentos de desenvolvimento seguro. Na Diretiva NIS2, a medida corresponde ao art. 21.º, n.º 2, alínea d). Nos termos do art. 10.º, n.º 2, do DL, estas disposições produzem efeitos a 22 de junho de 2028.

Para entidades que utilizam ferramentas DevSecOps ou scanners de segurança, o incidente Trivy demonstra que a avaliação de risco da cadeia de fornecimento deve incluir:

• Inventário de todas as ferramentas de segurança usadas em pipelines de CI/CD.
• Política de verificação de integridade de ferramentas antes de uso em ambientes de produção.
• Processo de atualização controlado com validação manual para ferramentas críticas.
• Monitorização de alertas de segurança dos projetos open-source utilizados.
• Avaliação periódica de alternativas e planos de substituição para ferramentas comprometidas.

Controlos imediatos recomendados

1. Auditar todas as ferramentas de segurança usadas em pipelines de CI/CD e verificar se existem alertas de segurança pendentes.
2. Implementar pinning de versões com checksums verificados para ferramentas críticas como scanners de containers, SAST e SCA, e referenciar GitHub Actions pelo SHA do commit.
3. Se a organização usou o Trivy v0.69.4 a v0.69.6 ou as actions trivy-action e setup-trivy por tag entre 19 e 23 de março de 2026, assumir o comprometimento dos segredos do pipeline e rodá-los.
4. Gerar e manter SBOMs para os próprios produtos/serviços da organização.
5. Subscrever canais de notificação de segurança (GitHub Security Advisories, OSV.dev) para as ferramentas utilizadas.
6. Testar planos de contingência para substituição rápida de ferramentas comprometidas.