Trivy ou Grype: como escolher para scan de imagens

Se você precisa escolher um scanner de vulnerabilidades para imagens de container e a lista curta tem Trivy e Grype, o critério prático é este: as duas ferramentas resolvem o problema central, e a decisão depende mais do que você quer escanear além da imagem e de como o resultado entra no seu pipeline. Este post propõe critérios para decidir e um teste que você mesmo pode rodar em uma tarde.

Nota: os comandos abaixo não foram executados neste ambiente; confira flags e formatos na documentação oficial antes de usar em produção. Este texto não traz benchmarks nem comparação de taxas de detecção — isso só faz sentido com o teste da sua própria base de imagens, descrito mais abaixo.

Cenário e critérios

Considere este cenário: uma equipe pequena de plataforma mantém imagens de aplicações em um registry privado e quer bloquear no CI imagens com vulnerabilidades críticas corrigíveis, além de gerar um relatório para auditoria.

Os critérios que costumam pesar nessa escolha:

1. Escopo de varredura. Só vulnerabilidades em pacotes, ou também configuração (IaC), segredos e licenças?
2. Integração com SBOM. Você já gera ou pretende gerar SBOM (lista de componentes do software)?
3. Formatos de saída. O CI e a ferramenta de gestão de vulnerabilidades consomem qual formato (JSON, SARIF, CycloneDX, SPDX)?
4. Controle de falha no pipeline. Como definir o limiar que quebra o build e como tratar falsos positivos aceitos?
5. Operação. Atualização da base de vulnerabilidades, uso em ambientes sem internet e cache no CI.
6. Ecossistema. O que você já usa: Kubernetes, registry, outras ferramentas da mesma empresa.

Diferenças práticas de desenho

Trivy, mantido pela Aqua Security, é posicionado como um scanner amplo. Além de imagens, cobre sistemas de arquivos, repositórios, manifestos de IaC, segredos e clusters Kubernetes, tudo com a mesma CLI — o escopo exato de cada tipo de alvo está documentado na documentação oficial do Trivy. Se você quer uma ferramenta única para vários tipos de alvo, isso reduz o número de peças a manter.

Grype, mantido pela Anchore, tem foco mais estreito em vulnerabilidades de imagens, diretórios e SBOMs. Ele costuma ser usado em par com o Syft, outra ferramenta da Anchore que gera SBOM. O fluxo típico é gerar o SBOM uma vez e escanear o SBOM, o que separa inventário de análise.

Isso não faz uma ferramenta melhor que a outra. Faz cada uma mais natural para um desenho de pipeline.

Como rodar os dois lado a lado

Comandos básicos de scan de uma imagem (não testados neste ambiente, confira na documentação oficial de cada projeto):

# Trivy: escanear imagem, mostrar só HIGH e CRITICAL
trivy image --severity HIGH,CRITICAL minha-app:1.4.2

# Grype: escanear a mesma imagem
grype minha-app:1.4.2

Para quebrar o build por severidade:

# Trivy: retorna código de saída 1 se encontrar CRITICAL
trivy image --severity CRITICAL --exit-code 1 minha-app:1.4.2

# Grype: falha se encontrar vulnerabilidade de severidade high ou acima
grype minha-app:1.4.2 --fail-on high

Note que os limiares não são equivalentes (no exemplo, um usa CRITICAL e o outro high). Ao comparar, alinhe a política primeiro, senão você compara regras diferentes e não ferramentas.

Fluxo com SBOM, que favorece o Grype quando o inventário já faz parte do processo:

syft minha-app:1.4.2 -o json > sbom.json
grype sbom:./sbom.json

Para gerar saída em JSON e comparar os resultados de forma objetiva:

trivy image -f json -o trivy.json minha-app:1.4.2
grype minha-app:1.4.2 -o json > grype.json

Um teste de comparação que vale a pena fazer

Em vez de confiar em opinião de terceiros (inclusive esta), monte um teste com o seu material:

1. Escolha de 5 a 10 imagens reais do seu ambiente, com bases diferentes (por exemplo, Debian, Alpine, distroless) e linguagens diferentes.
2. Rode as duas ferramentas com a base de dados atualizada no mesmo dia.
3. Compare, por imagem, o conjunto de CVEs que cada uma reporta e classifique as divergências: uma está certa, a outra está errada, ou é diferença de fonte de dados/severidade.
4. Meça o tempo de execução no seu CI, com e sem cache da base de dados.
5. Verifique como cada uma lida com o que você já aceitou como risco: arquivos de ignore, VEX ou equivalentes, conforme a documentação oficial.

As divergências entre scanners vêm em boa parte de fontes de dados e regras de correspondência diferentes. Por isso, o passo 3 é o mais informativo: ele mostra o que cada ferramenta perde ou exagera nas suas imagens, e não em imagens genéricas.

Recomendação condicionada

• Escolha Trivy se você quer uma CLI para imagem, IaC, segredos e cluster, e prefere menos ferramentas para manter.
• Escolha Grype (com Syft) se o SBOM é peça central do seu processo e você quer separar geração de inventário da análise de vulnerabilidades.
• Rodar as duas é válido em períodos de avaliação ou para auditorias que exigem uma segunda opinião, mas o custo é dobrar a triagem de resultados. Não faça isso indefinidamente sem um motivo claro.

Essa recomendação muda se o teste da seção anterior mostrar diferença relevante de detecção nas suas imagens, ou se restrições como ambiente sem internet ou exigência de formato específico de relatório favorecerem uma delas.

Próximo passo

Reserve uma tarde, rode o teste de 5 a 10 imagens com as duas ferramentas e registre as divergências em uma planilha simples. Com esse resultado, defina o limiar de falha do CI e adote uma das ferramentas como padrão. Só depois disso vale investir em ajustes finos, como arquivos de ignore e automação de atualização da base.