Equipes que provisionam nuvem com Terraform, Kubernetes e pipelines de entrega precisam de um scanner de infraestrutura como código (IaC) rodando antes do deploy, e a escolha entre Trivy e Checkov define qual tipo de erro consegue ser bloqueado automaticamente. A decisão errada não aparece no dia da instalação; aparece meses depois, quando a primeira configuração perigosa atravessa o pipeline porque o conjunto de políticas não cobria aquele recurso. A ação prioritária desta avaliação é fixar critérios objetivos — cobertura, linguagem de política, custo de manutenção e integração ao CI — antes de instalar qualquer uma das ferramentas.
O problema: escolha sem critério
Muitas equipes escolhem o scanner por indicação ou por já conhecer o nome do projeto. O resultado é uma ferramenta mal ajustada à realidade do repositório: dezenas de achados ignorados com o tempo, supressões espalhadas pelo código ou, no pior cenário, pipeline verde com buckets públicos e roles permissivas chegando à produção. Um scanner só entrega valor quando existe um critério explícito do que deve falhar o build e do que pode esperar. A discussão sobre controles contínuos sobre infraestrutura como código antecipa exatamente esse ponto: a ferramenta é o meio, o controle é o fim.
Cobertura e modelo de varredura
O Trivy concentra cinco famílias de verificação num único binário: vulnerabilidades conhecidas em dependências, configurações incorretas de IaC, segredos expostos, licenças de software e geração de SBOM. Os alvos vão de imagens de contêiner e sistemas de arquivos a repositórios Git remotos, imagens de máquinas virtuais e clusters Kubernetes inteiros. Essa amplitude é o principal argumento do projeto para equipes que querem um ponto de entrada único na cadeia de entrega, em vez de manter uma ferramenta para cada tipo de verificação.
Há também um fator de consolidação de mercado que pesa na decisão: o tfsec deixou de existir como projeto independente depois de ser incorporado ao Trivy pela Aqua. Quem ainda mantém pipelines com o binário antigo do tfsec está rodando código sem manutenção ativa, e a migração para o scanner de configurações incorretas do Trivy é obrigatória e não opcional. O repositório oficial do tfsec anuncia a transição na própria descrição, e a documentação do Trivy detalha como as verificações do tfsec, do Checkov, do kubesec e a verificação de Dockerfiles foram integradas ao módulo de configuração incorreta. Ignorar essa mudança transforma dívida silenciosa em risco de falso negativo.
Já o Checkov segue ativo como projeto de código aberto sob a Prisma Cloud, que absorveu a Bridgecrew e mantém o desenvolvimento. O projeto se descreve como analisador estático de infraestrutura como código e também como ferramenta de análise de composição de software para imagens e pacotes de código aberto. A variedade de formatos suportados é o diferencial estrutural: além de Terraform, o repositório oficial lista CloudFormation, AWS SAM, Kubernetes, Helm, Kustomize, Dockerfile, Serverless, Bicep, ARM e OpenTofu, o que cobre praticamente qualquer stack declarativa em produção.
Comparação por critério
| Critério | Trivy | Checkov |
|---|---|---|
| Escopo de varredura | Vulnerabilidades, configurações, segredos, licenças e SBOM | Configurações de IaC e análise de composição de pacotes |
| Formatos de IaC | Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, entre outros | Lista mais ampla, incluindo Bicep, Kustomize, ARM e OpenTofu |
| Política customizada | Regras em Rego sobre o modelo defsec | Políticas em Python e em YAML com grafo de recursos |
| Saída | JSON, tabela, SARIF, SBOM em formatos padrão | JSON, SARIF, JUnit, CycloneDX, CSV e markdown |
| Governança da política | Arquivos versionados no repositório | Idem, com ecossistema maior de políticas prontas documentadas |
Trivy: pontos fortes e limites
O ponto forte do Trivy é a economia operacional: um binário, um ciclo de atualização e uma saída padronizada para tudo. Para equipes que já centralizam a segurança de entrega num único estágio do pipeline, isso reduz a superfície de manutenção e o número de dependências a auditar. O projeto é mantido pela Aqua com lançamentos frequentes; no momento desta avaliação, a build estável mais recente é a 0.74.0. O limite prático está na profundidade de contexto: as verificações de configuração avaliam o que está declarado no diretório varrido, e a cobertura por linguagem de política em Rego exige familiaridade que nem toda equipe de plataforma tem. Vale lembrar que builds canary do projeto existem para testes, mas a própria documentação avisa que podem conter falhas críticas e não devem ser usadas em produção.
Checkov: pontos fortes e limites
O ponto forte do Checkov é a maturidade do catálogo: políticas integradas para AWS, Azure e Google Cloud, avaliação de variáveis aos valores padrão, detecção de credenciais embutidas em dados de usuário de EC2 e variáveis de ambiente de Lambda, e supressões inline documentadas para risco aceito. O modelo de grafo permite políticas compostas, que correlacionam recursos em vez de avaliar blocos isolados, o que reduz falsos positivos em arquiteturas reais. O limite é a natureza de ferramenta voltada a código e não a artefatos em execução: a análise de composição cobre pacotes e imagens, mas a varredura de segredos e licenças é menos central do que no Trivy, e a curva de políticas em Python exige disciplina de revisão para não virar código de segurança sem dono.
Plano de adoção prático
Antes de escolher, execute um piloto de duas semanas com a mesma amostra de repositórios nas duas ferramentas e meça três números internos: taxa de falsos positivos, tempo médio de correção de um achado e quantidade de verificações que a equipe suprimiu. A ferramenta vencedora é aquela cujos achados a equipe corrige, não a que gera mais alertas.
- P1 — bloquear o óbvio primeiro: rode o scanner no modo informativo por uma semana, classifique os achados recorrentes e então promova para falha de build apenas as verificações com remediação clara, como buckets sem criptografia e security groups abertos ao mundo.
- P1 — migrar o tfsec: se o pipeline ainda chama o binário legado, substitua pela varredura de configuração do Trivy no mesmo estágio e registre a mudança no changelog do repositório.
- P2 — política própria versionada: escreva a primeira política customizada para um controle que só existe na sua arquitetura, com teste automatizado, para validar a curva da linguagem de política antes de depender dela.
- P2 — integrar ao fluxo de segredos: conecte os achados de credenciais expostas ao processo descrito no guia sobre segredos no CI/CD e bloqueio de vazamentos antes do deploy, com rotação obrigatória para todo segredo detectado no histórico.
Se a equipe mantém múltiplos tipos de artefato e quer um único estágio de verificação, o Trivy tende a vencer por escopo. Se o problema central é governança de configuração declarativa multi-nuvem com políticas compostas, o Checkov tende a vencer por profundidade. Nenhuma das duas escolhas dispensa revisão humana de arquitetura: scanner avalia o que foi declarado, não o que foi esquecido de declarar.