Em março de 2026, milhares de pipelines de CI/CD confiaram cegamente numa imagem Docker marcada como “latest”. Essa imagem continha uma versão comprometida do Trivy, o scanner de vulnerabilidades da Aqua Security. O incidente reacendeu uma pergunta que grande parte das equipas de engenharia ainda não resolveu: qual ferramenta protege melhor a cadeia de fornecimento de software, um scanner tudo-em-um como o Trivy, a dupla Syft mais Grype da Anchore, ou a infraestrutura de assinatura Sigstore com o Cosign? Este artigo compara as três abordagens com dados verificáveis, sem espaço para achismo.
A pergunta importa porque a superfície de ataque mudou. Já não basta escanear o código-fonte antes do deploy. Os atacantes agora visam as próprias ferramentas de segurança, os binários publicados em registos públicos e as GitHub Actions que compõem o pipeline. O caso Trivy prova isso. Os CVEs recentes no Cosign, usados por milhares de projetos para assinar artefactos, provam o mesmo. Escolher a arquitetura certa deixou de ser uma questão de preferência técnica e passou a ser uma decisão de risco.
Neste artigo analisamos as três ferramentas lado a lado com dados de fontes verificáveis: relatórios oficiais da Aqua Security e da Apache Software Foundation sobre o incidente do Trivy, bases de dados de CVE para as falhas do Cosign, e listagens públicas de preços no AWS Marketplace para as camadas comerciais de cada projeto. Onde não encontrámos números fiáveis, como benchmarks independentes de velocidade de scan, dizemos isso de forma explícita em vez de preencher a lacuna com estimativas. O objetivo é dar a uma equipa técnica portuguesa os elementos concretos para decidir, não uma opinião genérica sobre “boas práticas de segurança”.
O que faz cada ferramenta: visão técnica rápida
O Trivy, mantido pela Aqua Security, é um scanner tudo-em-um. Ele analisa imagens de contentores, sistemas de ficheiros, repositórios Git e clusters Kubernetes à procura de vulnerabilidades conhecidas, segredos expostos e configurações incorretas. Também gera SBOMs (Software Bill of Materials) diretamente, nos formatos CycloneDX e SPDX. É a ferramenta que mais equipas pequenas instalam primeiro, precisamente porque resolve várias tarefas com um único binário.
Syft e Grype, ambos da Anchore, seguem uma filosofia diferente: dividir para conquistar. O Syft gera o SBOM (inventário de componentes de software), suportando CycloneDX em JSON e XML, SPDX em JSON e formato tag-value, além do formato nativo da própria ferramenta. O Grype consome esse SBOM, ou escaneia diretamente uma imagem, e cruza os componentes com bases de dados de vulnerabilidades. Separar geração de SBOM e deteção de CVEs em dois binários dá mais controlo a equipas que querem trocar apenas uma peça do pipeline sem mexer na outra.
O Cosign, parte do projeto Sigstore, não escaneia nada. Assina e verifica. A ferramenta permite assinar imagens de contentores e outros artefactos, anexar atestados (incluindo SBOMs em CycloneDX) e confirmar que uma imagem publicada não foi alterada depois de sair do pipeline oficial. Sem assinatura, um SBOM ou um relatório de scan “limpo” não garante nada sobre a proveniência real da imagem que corre em produção.
Esta distinção de papéis explica por que comparar as três ferramentas como se fossem opções concorrentes, do género “qual delas é melhor”, simplifica demasiado o problema. A pergunta mais útil para uma equipa de engenharia é outra: qual combinação destas camadas cobre os riscos que a organização realmente enfrenta, dentro do orçamento e do tempo de manutenção disponíveis. É essa a lente usada no resto deste artigo.
O ataque à cadeia de fornecimento do Trivy em março de 2026
O incidente começou a 19 de março de 2026. Segundo a reportagem da The Hacker News, o binário do Trivy na versão v0.69.4 esteve comprometido durante cerca de três horas antes de ser detetado. Dias depois, entre 22 e 24 de março, as versões v0.69.5, v0.69.6 e a etiqueta “latest” ficaram expostas no Docker Hub durante aproximadamente dez horas. A ação do GitHub trivy-action, usada em milhares de workflows, também foi afetada nas tags 0.0.1 até 0.34.2, com uma janela de exposição de cerca de doze horas.
O relatório inicial da Apache Software Foundation, publicado no blog oficial da Apache, confirma que o binário malicioso da versão 0.69.4 tinha capacidade de roubar credenciais armazenadas em GitHub Secrets. Isto significa que projetos que executavam o Trivy em pipelines automatizados podiam ter tokens de acesso, chaves de API e credenciais de deploy expostas sem qualquer interação humana. A recomendação de mitigação foi direta: voltar à versão v0.69.3 ou anterior, fixar trivy-action na 0.35.0 e setup-trivy na 0.2.6, sempre com referência a um hash SHA específico em vez de uma etiqueta de versão.
Apesar do susto, o desenvolvimento do Trivy não parou. Em julho de 2026 saiu a versão v0.71.0, que adicionou deteção de vulnerabilidades em aplicações .NET e suporte ao padrão CycloneDX 1.6 para geração de SBOM, além de otimizações de desempenho nas atualizações de base de dados. O episódio deixou uma lição que se aplica a qualquer uma das três ferramentas discutidas neste artigo: confiar numa etiqueta “latest” sem fixação por hash é, na prática, confiar cegamente em quem publica essa etiqueta.
As falhas recentes no Cosign: CVE-2026-39395 e CVE-2026-22703
Se o Trivy sofreu um ataque de distribuição, o Cosign sofreu algo mais subtil: falhas na própria lógica de verificação. A base de dados de vulnerabilidades da SentinelOne documenta o CVE-2026-39395, publicado em abril de 2026. O comando cosign verify-blob-attestation podia devolver “Verified OK” para atestados com payloads malformados ou tipos de predicado inconsistentes. Numa ferramenta cujo único propósito é confirmar autenticidade, um falso positivo deste tipo anula o valor de toda a cadeia de confiança construída à volta dela.
A falha afetava versões anteriores à 3.0.6 (linha 3.x) e à 2.6.3 (linha 2.x). O projeto Sigstore corrigiu o problema reforçando a validação de tipos de predicado e o tratamento de bundles antigos. Pouco tempo antes, o CVE-2026-22703, catalogado como insuficiência de verificação de dados, já tinha sido corrigido nas versões 2.6.2 e 3.0.4. Organizações europeias receberam recomendação explícita para atualizar de imediato, dado o peso regulatório crescente sobre assinatura de software na União Europeia.
Quem quiser confirmar a versão instalada e atualizar pode correr o seguinte comando:
cosign version
go install github.com/sigstore/cosign/v2/cmd/[email protected]Em agosto de 2026, o projeto já tinha avançado para a v2.6.4, segundo o histórico de lançamentos no repositório oficial do Sigstore. Manter o Cosign atualizado deixou de ser opcional para quem depende dele como última linha de defesa contra imagens adulteradas.
Tabela de especificações: Trivy vs Syft+Grype vs Sigstore/Cosign
A tabela abaixo resume as diferenças técnicas fundamentais entre as três abordagens, com base na documentação oficial de cada projeto e nos incidentes de segurança documentados em 2026.
| Critério | Trivy | Syft + Grype | Sigstore / Cosign |
|---|---|---|---|
| Mantenedor | Aqua Security | Anchore | Linux Foundation / OpenSSF |
| Função principal | Scanner tudo-em-um | Geração de SBOM + scanner de CVEs | Assinatura e verificação de artefactos |
| Licença | Apache 2.0 (open source) | Apache 2.0 (open source) | Apache 2.0 (open source) |
| Formatos de SBOM | CycloneDX, SPDX (JSON e tag-value) | CycloneDX (JSON/XML), SPDX (JSON/tag-value), formato nativo | Consome atestados CycloneDX desde a v1.10.0 |
| Alvos de análise | Imagens, sistemas de ficheiros, Git, Kubernetes | Imagens, diretórios, repositórios de código | Imagens de contentores e binários assinados |
| Deteção de segredos | Sim, nativa | Não (fora do âmbito) | Não (fora do âmbito) |
| Integração nativa GitHub Actions | Sim (trivy-action) | Sim (syft-action, grype-action) | Sim (cosign-installer) |
| Assinatura de artefactos | Não | Não | Sim, core da ferramenta |
| Versão estável mais recente | v0.71.0 (julho de 2026) | Syft v1.42.4 (agosto de 2026) | Cosign v2.6.4 (agosto de 2026) |
| Estrelas no GitHub | Cerca de 36.500 | Cerca de 8.400 (Syft) | Não divulgado nas fontes consultadas |
| Modelo de preços | Grátis (OSS) + Aqua Platform comercial | Grátis (OSS) + Anchore Enterprise comercial | Grátis (OSS), sem SKU empresarial próprio |
| Camada empresarial de terceiros | Aqua Platform | Anchore Enterprise | Chainguard (imagens pré-assinadas) |
Repare num detalhe que costuma passar despercebido: nenhuma das três ferramentas substitui as outras. O Trivy deteta vulnerabilidades, o Syft descreve o que está dentro de uma imagem e o Cosign garante que essa imagem chegou intacta até quem a vai executar. Tratá-las como concorrentes diretas é um erro de enquadramento comum entre equipas que só descobrem a diferença depois de um incidente.
Formatos de SBOM: CycloneDX contra SPDX na prática
A escolha do formato de SBOM não é um detalhe cosmético, sobretudo com a entrada em vigor de exigências regulatórias europeias. O CycloneDX, mantido pela OWASP, foi desenhado com foco em segurança e é o formato preferido por reguladores que exigem rastreabilidade de vulnerabilidades. O SPDX, gerido pela Linux Foundation, nasceu com foco em conformidade de licenciamento e continua a ser exigido em contratos governamentais nos Estados Unidos.
O Trivy gera SBOM diretamente com um único comando:
trivy image --format cyclonedx --output sbom.json minha-imagem:tag
trivy image --format spdx-json --output sbom-spdx.json minha-imagem:tagO Syft cobre o mesmo terreno, mas com mais opções de formato de saída:
syft dir:. -o cyclonedx-json=sbom.cdx.json
syft minha-imagem:tag -o spdx-json=sbom.spdx.jsonA integração entre os dois mundos acontece quando o SBOM gerado pelo Syft é assinado e anexado como atestado pelo Cosign. Desde a versão 0.40.0, o Syft inclui o comando syft attest, que usa chaves geradas pelo Cosign para criar atestados de SBOM assinados diretamente, sem passar por ficheiros intermédios. Esse fluxo completo, gerar, assinar, anexar, é o que separa uma equipa que apenas “escaneia” de uma equipa que consegue provar a origem de cada imagem publicada.
Há ainda uma diferença prática entre os dois formatos que raramente aparece nos tutoriais rápidos. O CycloneDX foi construído a pensar em ciclos curtos de atualização, com uma estrutura pensada para acompanhar dependências que mudam a cada build. O SPDX tende a ser mais verboso e mais próximo do mundo jurídico, o que o torna mais lento de gerar em pipelines com milhares de componentes. Equipas que precisam de velocidade no CI tendem a gerar CycloneDX por omissão e só produzir SPDX quando um cliente ou regulador o exige explicitamente. Isso evita duplicar trabalho sem abdicar de conformidade quando ela é mesmo pedida.
Como as três ferramentas se encaixam num pipeline real
A teoria ajuda pouco sem ver o encadeamento completo. Um pipeline de CI/CD que combina as três camadas costuma seguir uma sequência previsível: build da imagem, geração do SBOM, scan de vulnerabilidades sobre esse SBOM, assinatura da imagem e, por fim, anexação do SBOM como atestado assinado. Cada etapa depende da anterior, mas nenhuma delas substitui a seguinte.
# 1. Build da imagem
docker build -t registo.exemplo.pt/app:1.4.0 .
# 2. Gerar SBOM com Syft
syft registo.exemplo.pt/app:1.4.0 -o cyclonedx-json=sbom.json
# 3. Escanear o SBOM com Grype
grype sbom:sbom.json --fail-on high
# 4. Assinar a imagem com Cosign
cosign sign --key cosign.key registo.exemplo.pt/app:1.4.0
# 5. Anexar o SBOM como atestado assinado
cosign attest --key cosign.key --predicate sbom.json --type cyclonedx registo.exemplo.pt/app:1.4.0Repare que o passo três usa a flag –fail-on high, que interrompe o pipeline caso o Grype encontre uma vulnerabilidade de severidade alta ou crítica no SBOM gerado. É essa porta de bloqueio que transforma um scanner de “relatório informativo” em “guarda de qualidade” real. Sem ela, um relatório com dez vulnerabilidades críticas passa despercebido se ninguém tiver tempo de o ler manualmente todos os dias.
Quem prefere manter tudo dentro de um único binário pode substituir os passos dois e três pelo Trivy, que gera o SBOM e escaneia ao mesmo tempo. A diferença prática é que, ao separar Syft e Grype, uma falha ou incidente numa das ferramentas não compromete automaticamente a outra, algo que o próprio caso do Trivy em março de 2026 tornou mais do que um argumento teórico.
Adoção e maturidade: o que os dados mostram
Não existem, à data desta análise, benchmarks independentes de velocidade de scan que comparem diretamente Trivy, Grype e Cosign em condições controladas e publicadas. Preferimos dizer isto com clareza a inventar números. Em vez disso, cruzamos três indicadores de maturidade que são publicamente verificáveis e que, juntos, funcionam como um proxy razoável de confiança e adoção no ecossistema.
| Indicador | Trivy | Syft / Grype | Sigstore / Cosign | Fonte |
|---|---|---|---|---|
| Estrelas no GitHub | ~36.500 | ~8.400 (Syft) | Repositório ativo, sem contagem pública nas fontes consultadas | AppSec Santa |
| Cadência de lançamentos | Mensal a bimestral | Mensal (Syft v1.42.0 em fevereiro, v1.42.4 em agosto) | Ativa, múltiplos patches de segurança em 2026 | GitHub Releases / Anchore |
| Correções de segurança publicadas em 2026 | 1 incidente de cadeia de fornecimento (março) | Sem incidentes documentados nas fontes consultadas | 2 CVEs corrigidos (abril e período anterior) | SentinelOne, OffSeq, The Hacker News |
| Cobertura em análises de mercado | Referência recorrente em comparadores de fornecedores | Descrito como “o componente silencioso por trás da maioria dos workflows de SBOM” | Referenciado como infraestrutura crítica de confiança para artefactos | AppSec Santa, StackRadar |
O padrão que emerge não é sobre qual ferramenta é mais rápida. É sobre exposição e resposta. O Trivy sofreu um ataque direto e respondeu com patches e documentação de mitigação em poucas horas. O Cosign sofreu falhas de lógica interna, não de distribuição, e corrigiu-as com o mesmo ritmo. Nenhuma das ferramentas é invulnerável. A diferença está em como cada projeto reage quando algo corre mal, e isso conta tanto ou mais do que a contagem de estrelas no GitHub.
Tabela de preços: do open source ao contrato empresarial
As três ferramentas são gratuitas na sua forma núcleo. As diferenças aparecem quando uma organização precisa de dashboards centralizados, políticas de bloqueio automático, suporte contratual com SLA ou auditoria de conformidade. Os valores abaixo vêm de listagens públicas no AWS Marketplace e das páginas de preços dos próprios fornecedores.
| Camada | Trivy / Aqua Platform | Syft+Grype / Anchore Enterprise | Sigstore/Cosign / Chainguard |
|---|---|---|---|
| Ferramenta base | Grátis (Apache 2.0) | Grátis (Apache 2.0) | Grátis (Apache 2.0) |
| Entrada comercial (anual) | ≈ $50.000 (plano Shift Left, AWS Marketplace) | ≈ $34.500 (Anchore Enterprise Cloud Image, AWS Marketplace) | $0, até 5 imagens por organização (Chainguard free) |
| Plano intermédio (anual) | ≈ $100.000 (plano Protect) | ≈ $50.000 (Anchore Enterprise Helm) | A partir de ≈ $19.000 para equipa de 10 (Chainguard Teams) |
| Plano avançado (anual) | ≈ $150.000 (plano Ultimate) | Contrato personalizado | Contrato personalizado (Chainguard Enterprise) |
| Plano de suporte adicional | Incluído nos tiers acima | ≈ $15.000 (Essential Customer Success Plan) | Não aplicável (Cosign não tem SKU próprio) |
| Modelo de cobrança | Contrato anual, sob consulta | Contrato anual, sob consulta | Mensal ou anual, conforme catálogo |
Vale sublinhar que o Cosign, ao contrário do Trivy e do Syft/Grype, não tem uma versão empresarial própria vendida pelo projeto Sigstore. Quem quer uma camada comercial construída à volta de imagens assinadas normalmente recorre à Chainguard, que oferece imagens de base já endurecidas e assinadas com Sigstore, com um tier gratuito limitado a cinco imagens por organização.
Cinco exemplos reais de 2026 que mudam a forma de decidir
Números em tabela ajudam, mas são os casos concretos que mostram onde cada ferramenta falha ou funciona sob pressão real.
1. O binário malicioso v0.69.4 do Trivy
Durante uma janela de poucas horas, quem baixou o binário oficial do Trivy recebeu código capaz de roubar segredos do GitHub Actions. O ataque não explorou uma vulnerabilidade de código, explorou a confiança automática numa etiqueta de versão. Equipas que usavam “latest” em vez de uma versão fixa ficaram expostas assim que fizeram o próximo pull da imagem, sem qualquer ação adicional da sua parte. O caso mostrou que a comodidade de seguir sempre a versão mais recente tem um custo de segurança que raramente é discutido antes de um incidente acontecer.
2. O bypass de verificação no Cosign (CVE-2026-39395)
Um atestado malformado podia passar como “Verified OK”. Equipas que confiavam apenas no resultado binário do comando, sem inspeção adicional, estiveram expostas durante o período anterior ao patch de abril de 2026. O caso é particularmente instrutivo porque a falha não estava em nenhuma dependência externa, estava na própria lógica de validação da ferramenta desenhada para garantir confiança. Isso reforça a ideia de que assinatura digital não é uma garantia absoluta, é uma camada de defesa que precisa de ser mantida atualizada como qualquer outra.
3. A segunda falha do Cosign, corrigida antes da primeira ser pública
O CVE-2026-22703 foi corrigido nas versões 2.6.2 e 3.0.4, mostrando que mesmo ferramentas dedicadas exclusivamente a segurança acumulam falhas com regularidade. Isso reforça por que fixar versões e monitorizar avisos é tão importante quanto escolher a ferramenta certa. Organizações que atualizaram apenas depois do primeiro CVE ficaram, sem saber, ainda expostas ao segundo problema durante semanas, o que mostra a importância de aplicar sempre a versão mais recente da linha estável em vez de correr atrás de cada CVE individualmente.
4. Contratos empresariais de seis dígitos no AWS Marketplace
As listagens públicas de preços da Aqua Platform e da Anchore Enterprise, entre $34.500 e $150.000 por ano, mostram que empresas de média e grande dimensão já tratam este tipo de ferramenta como infraestrutura crítica, não como um extra opcional de segurança. O salto de preço entre o tier de entrada e o tier avançado da Aqua Platform, de $50.000 para $150.000, também sugere que grande parte do valor cobrado está ligado ao volume de imagens escaneadas e ao número de integrações suportadas, não apenas ao acesso ao produto em si.
5. A integração Syft attest com o Cosign
O comando syft attest, que assina SBOMs diretamente com chaves Cosign, mostra a direção para onde o ecossistema caminha: menos ferramentas isoladas, mais fluxos combinados onde geração de SBOM e assinatura acontecem no mesmo passo do pipeline. Este tipo de integração nativa entre projetos distintos da Cloud Native Computing Foundation reduz o número de scripts de cola que as equipas precisam de manter, e é um indicador razoável de que o ecossistema está a amadurecer para além de ferramentas isoladas.
6. O ritmo de lançamentos do Syft como sinal de manutenção ativa
Entre fevereiro e agosto de 2026, o Syft passou da versão v1.42.0 para a v1.42.4, um ritmo de lançamentos menores mas constantes. Para equipas que avaliam a viabilidade a longo prazo de uma ferramenta open source, a cadência de releases costuma ser um indicador mais fiável do que o número de estrelas no GitHub, porque mostra manutenção ativa em vez de popularidade histórica.
Vantagens e desvantagens de cada abordagem
Trivy. A favor: um único binário cobre scanning de vulnerabilidades, deteção de segredos, configuração incorreta e geração de SBOM. Curva de aprendizagem curta, o que ajuda equipas pequenas a implementar segurança de cadeia de fornecimento sem contratar um especialista dedicado. Documentação extensa e integração nativa com GitHub Actions através do trivy-action. Contra: o incidente de março de 2026 mostrou que centralizar tantas funções num só binário também centraliza o risco caso esse binário seja comprometido. Depender de uma única ferramenta para scanning e SBOM também significa que qualquer bug de deteção afeta ambas as funções ao mesmo tempo.
Syft + Grype. A favor: separação de responsabilidades reduz a superfície de ataque de cada componente e permite trocar apenas uma peça sem afetar a outra. Suporte de formatos SBOM particularmente amplo, incluindo CycloneDX em XML, uma opção que o Trivy não oferece. A comunidade da Anchore mantém um ritmo de lançamentos consistente, o que reduz o risco de ficar com uma ferramenta abandonada. Contra: exige manter e atualizar dois binários em vez de um, e a configuração inicial do pipeline demora mais tempo. Equipas pequenas sem experiência prévia em segurança de pipeline tendem a sentir mais fricção nesta fase de configuração do que com o Trivy.
Sigstore / Cosign. A favor: é a única das três camadas que responde à pergunta “esta imagem é mesmo a que eu publiquei?”. Sem assinatura, um SBOM limpo não impede substituição da imagem depois do build. É mantido pela Linux Foundation através do OpenSSF, o que lhe dá um perfil de governação mais neutro do que ferramentas ligadas a uma única empresa. Contra: não deteta vulnerabilidades nem gera inventário, precisa de ser combinado com outra ferramenta para ter utilidade prática, e as duas falhas de 2026 mostram que a própria camada de confiança também erra. A gestão de chaves, embora simplificada em relação a soluções de assinatura mais antigas, ainda exige atenção redobrada em ambientes com múltiplas equipas a publicar imagens.
Casos de uso: qual ferramenta escolher em cada cenário
Nenhuma das três ferramentas é universalmente certa. A escolha depende do tamanho da equipa, do sector regulatório e de quanto tempo de engenharia existe disponível para manter o pipeline de segurança. Os seis cenários abaixo cobrem a maioria das situações que equipas portuguesas enfrentam ao decidir esta arquitetura em 2026.
Startups e equipas pequenas com orçamento apertado. Trivy sozinho, fixado por hash SHA, resolve scanning e geração de SBOM sem custo e sem complexidade adicional de pipeline.
Organizações reguladas em banca ou saúde. A combinação Anchore Enterprise ou Aqua Platform, com dashboards centralizados e trilha de auditoria, justifica o investimento quando existe obrigação de compliance e reporte a reguladores.
Equipas já fortemente investidas em GitHub Actions. Trivy com trivy-action, complementado por cosign-installer para assinar o resultado final, cobre o essencial sem adicionar um terceiro sistema.
Projetos que precisam de provas de proveniência para conformidade com o Cyber Resilience Act. A combinação Syft, para geração de SBOM, mais Cosign, para assinatura e atestado, é a que melhor demonstra origem verificável de cada artefacto, um requisito cada vez mais citado pela regulação europeia.
Equipas que preferem não gerir imagens de base própria. Um catálogo pré-endurecido e pré-assinado como o da Chainguard elimina parte do trabalho de manutenção, ao custo de depender de um fornecedor externo para a camada base.
Mantenedores de projetos open source sem orçamento. A combinação totalmente gratuita de Syft, Grype e Cosign cobre geração de SBOM, deteção de vulnerabilidades e assinatura sem custo, exigindo apenas tempo de configuração.
Empresas de consultoria que gerem pipelines para múltiplos clientes. A separação entre Syft e Grype facilita a padronização de políticas diferentes por cliente, algo mais difícil de isolar quando scanning e SBOM saem da mesma ferramenta configurada de forma única para todos os projetos.
Guia de migração: construir um pipeline de segurança de cadeia de fornecimento
Migrar de um scanner isolado para uma arquitetura em camadas não precisa de ser feito de uma vez. Equipas que tentam implementar as três ferramentas no mesmo sprint costumam desistir a meio, porque cada camada exige ajustes próprios de configuração e testes. A abordagem que funciona melhor na prática é incremental: uma etapa de cada vez, validada em ambiente de staging antes de se tornar obrigatória em produção. Os passos abaixo seguem a ordem que reduz risco mais depressa, começando pela lição mais direta do incidente do Trivy.
- Audite o pipeline atual e identifique cada ponto onde uma imagem ou binário é referenciado por etiqueta flutuante, como “latest”, sem hash fixo.
- Substitua todas as referências por pinning em SHA específico. Para o Trivy, use v0.69.3 ou superior, trivy-action 0.35.0 e setup-trivy 0.2.6 como base mínima segura.
- Adicione geração de SBOM com o Syft em formato CycloneDX, correndo em paralelo ao scanner principal, não como substituto dele.
- Atualize o Cosign para 3.0.6 na linha 3.x, ou 2.6.3 na linha 2.x no mínimo, cobrindo os dois CVEs de 2026, e assine todas as imagens que saem do pipeline oficial.
- Use o comando syft attest para anexar o SBOM como um atestado assinado diretamente à imagem, ligando geração de inventário e prova de autenticidade num único passo.
- Escaneie o SBOM gerado com o Grype de forma independente do Trivy, criando uma segunda opinião que não depende do mesmo motor de deteção.
- Configure uma porta de verificação obrigatória no CI/CD que bloqueia o deploy de qualquer imagem sem assinatura Cosign válida.
- Monitorize avisos de segurança dos três projetos e o catálogo CISA KEV para identificar rapidamente se algum componente do próprio pipeline for afetado.
Equipas maiores, com múltiplas linhas de produto, tendem a adicionar uma nona etapa: avaliar se o volume de imagens justifica migrar para Anchore Enterprise ou Aqua Platform, que centralizam o resultado destas etapas num único painel com histórico e políticas configuráveis por equipa.
O peso do Cyber Resilience Act na escolha da arquitetura
A regulação europeia deixou de tratar SBOM e assinatura de software como boas práticas opcionais. O Cyber Resilience Act exige que fabricantes de produtos com elementos digitais documentem a composição do software e mantenham processos de gestão de vulnerabilidades ao longo do ciclo de vida do produto. Isso empurra diretamente para o tipo de fluxo descrito neste artigo: geração de SBOM em formato padronizado, scanning contínuo e prova de proveniência assinada.
Empresas portuguesas que vendem software ou dispositivos conectados dentro da União Europeia já sentem esta pressão nos contratos com clientes empresariais, que cada vez mais pedem o SBOM como anexo obrigatório da proposta. Nesse contexto, escolher apenas um scanner sem camada de assinatura deixa uma lacuna que auditores de conformidade tendem a assinalar primeiro.
Na prática, isto muda a ordem de prioridades para equipas de engenharia em Portugal. Antes, a pergunta habitual era “este código tem vulnerabilidades conhecidas?”. Agora, a pergunta que um auditor ou um cliente empresarial faz é mais ampla: “consegue mostrar-me exatamente o que está dentro deste produto, e provar que ninguém alterou esse inventário depois de o publicar?”. Só a combinação de geração de SBOM com assinatura responde de forma completa a essa segunda pergunta, o que explica por que cada vez mais equipas técnicas tratam Cosign como parte obrigatória do pipeline, e não como um extra de segurança avançada.
Veredito: qual ferramenta escolher em 2026
Não existe vencedor único, porque as três ferramentas resolvem problemas diferentes. Mas os dados deste artigo apontam para uma conclusão prática. Trivy continua a ser a opção mais rápida de adotar para quem precisa de scanning e geração de SBOM num único passo, desde que a lição de março de 2026 seja levada a sério, nunca correr sem pinning por hash. Syft e Grype ganham quando a prioridade é flexibilidade de formatos e separação de responsabilidades, especialmente em organizações que já têm equipas dedicadas a segurança de pipeline. Sigstore e Cosign não competem com nenhuma das duas, são o complemento que falta em praticamente todos os pipelines que ainda não os usam.
Para a maioria das equipas portuguesas que avaliam este investimento em 2026, a combinação mais equilibrada entre custo e cobertura é Trivy fixado por hash para scanning diário, complementado por Cosign para assinatura de tudo o que sai para produção. Equipas com exigências regulatórias mais pesadas, sobretudo as abrangidas pelo Cyber Resilience Act, ganham mais ao adotar Syft e Grype pela riqueza de formatos SBOM, sempre com Cosign a fechar o ciclo de confiança.
O critério de decisão mais simples continua a ser o orçamento de tempo de engenharia disponível, não o preço das licenças. As três ferramentas núcleo são gratuitas, o que significa que a maior parte do custo real está no trabalho de configurar o pipeline, treinar a equipa e manter as versões atualizadas ao longo do tempo. Organizações que subestimam esse custo operacional acabam por instalar uma ferramenta e nunca a atualizar, o que, como mostrou o incidente do Trivy, é exatamente o cenário que cria a maior exposição a risco.
Perguntas frequentes
O Trivy ainda é seguro de usar depois do ataque de março de 2026?
Sim, desde que a instalação use versões pinadas por hash SHA, v0.69.3 ou superior para o binário, trivy-action 0.35.0, setup-trivy 0.2.6, em vez de confiar em etiquetas flutuantes como “latest”. A Aqua Security manteve o desenvolvimento ativo, com a v0.71.0 lançada em julho de 2026.
Preciso de usar as três ferramentas ao mesmo tempo?
Não é obrigatório, mas recomenda-se. Um scanner sozinho, Trivy ou Grype, deteta vulnerabilidades, mas não prova que a imagem final não foi alterada depois do build. Adicionar Cosign fecha essa lacuna sem grande esforço adicional de configuração.
Qual formato de SBOM devo escolher, CycloneDX ou SPDX?
CycloneDX tende a ser preferido por reguladores europeus focados em segurança, incluindo o contexto do Cyber Resilience Act. SPDX continua relevante para contratos que exigem conformidade de licenciamento, sobretudo nos Estados Unidos. As três ferramentas discutidas suportam ambos.
O Cosign tem uma versão paga própria?
Não. O Cosign e o projeto Sigstore são totalmente open source, sem SKU empresarial. Quem procura uma camada comercial construída à volta de imagens assinadas costuma recorrer à Chainguard, que vende acesso a um catálogo de imagens pré-endurecidas e já assinadas.
Quanto custa a versão empresarial do Trivy ou do Syft/Grype?
Segundo listagens públicas no AWS Marketplace, a Aqua Platform, camada comercial do Trivy, varia entre cerca de $50.000 e $150.000 por ano, consoante o tier. A Anchore Enterprise, camada comercial de Syft e Grype, varia entre cerca de $34.500 e $50.000 por ano, mais um plano de suporte adicional de cerca de $15.000. Ambos os fornecedores tratam preços finais como sob consulta.
Estas ferramentas funcionam fora de contentores Docker?
Sim. O Trivy escaneia sistemas de ficheiros, repositórios Git e clusters Kubernetes, além de imagens. O Syft gera SBOM a partir de diretórios de código-fonte e não apenas de imagens de contentores. O Cosign assina qualquer artefacto binário, não se limita a imagens OCI.
O que muda com o Cyber Resilience Act para quem usa estas ferramentas?
A regulação europeia pressiona fabricantes de software a documentar a composição dos seus produtos e a manter gestão contínua de vulnerabilidades. Isso torna a combinação de geração de SBOM e assinatura de artefactos menos uma escolha técnica e mais um requisito de conformidade para quem vende dentro da União Europeia.
É seguro migrar de um scanner único para uma arquitetura em três camadas sem interromper o pipeline atual?
Sim, desde que a migração seja feita de forma incremental. Adicionar geração de SBOM e assinatura em paralelo ao scanner existente, sem removê-lo, permite validar a nova arquitetura antes de tornar qualquer etapa obrigatória. Só depois de confirmar que o novo fluxo funciona de forma estável é que faz sentido transformar a verificação de assinatura numa porta de bloqueio no CI/CD.
