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: Comprometimento do pipeline CI/CD do projeto, com injeção de código malicioso em binário assinado.

Padrão observado: Atacantes estado-nação e grupos APT têm mudado o foco de alvos diretos para comprometer a cadeia de ferramentas usada pelos próprios equipas de segurança. Quem analisa vulnerabilidades tornou-se o alvo.

Método do ataque ao Trivy

De acordo com a análise do incidente publicada pelos investigadores, o ataque ao Trivy seguiu a metodologia típica de comprometimento de pipelines CI/CD:

  1. Comprometimento de credenciais de contribuidor: Acesso indevido a uma conta com permissões de merge no repositório principal do projeto.
  2. Pull Request malicioso: Introdução de código aparentemente inocente que modificava a lógica de output do scanner para, em certos contextos de rede, exfiltrar informação de ambiente.
  3. Injeção no pipeline de build: O código comprometido passou a integrar os binários compilados e assinados digitalmente pela infraestrutura do projeto.
  4. Distribuição via canais legítimos: Os binários infetados foram distribuídos através do GitHub Releases oficial e dos repositórios de packages (Homebrew, APT, rpm).

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 a assinatura digital não basta

Um dos pontos mais relevantes deste incidente é que os binários comprometidos estavam assinados digitalmente com as chaves legítimas do projeto. A assinatura de código confirma que o binário não foi adulterado após a compilação, mas não garante a integridade do código-fonte nem do processo de compilação.

O que é necessário além da assinatura de código

  • 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. 21.º n.º 2 alínea d) do DL 125/2025 estabelece explicitamente como medida obrigatória a "segurança na cadeia de abastecimento, incluindo os aspetos de segurança relativos às relações entre cada entidade e os seus fornecedores ou prestadores de serviços".

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.

Referência normativa BSI: O BSI TR-03183-2 (Alemanha) exige SBOM em formato SPDX ou CycloneDX para todos os componentes de software em entidades críticas. Este é o padrão de facto que o CNCS deverá seguir ao publicar requisitos técnicos detalhados ao abrigo do DL 125/2025.

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.
  3. Gerar e manter SBOMs para os próprios produtos/serviços da organização.
  4. Subscrever canais de notificação de segurança (GitHub Security Advisories, OSV.dev) para as ferramentas utilizadas.
  5. Testar planos de contingência para substituição rápida de ferramentas comprometidas.