CRACI vs Trivy

A resposta curta

O Trivy é uma das ferramentas de segurança gratuitas mais úteis que existem. Analisa imagens de contentores, sistemas de ficheiros, repositórios, imagens de máquinas virtuais e Kubernetes em busca de vulnerabilidades, configurações incorretas, segredos e licenças, e emite SBOM como efeito secundário. O CRACI é um runner de GitHub Actions que regista o que cada build obteve, controla a que o build se pode ligar e continua a acompanhar as vulnerabilidades no que foi distribuído. A diferença essencial: o Trivy infere a lista de componentes a partir de ficheiros, enquanto o CRACI a observa. Para a SBOM e as vulnerabilidades de dependências do software que constrói, o CRACI substitui o Trivy. Para o resto do que o Trivy analisa, escolha uma ferramenta por tarefa na lista abaixo.

Porque é que as equipas procuram alternativas ao Trivy

• O comprometimento da cadeia de abastecimento de março de 2026. O aviso de segurança da Aqua Security (CVE-2026-33634) descreve uma versão maliciosa do Trivy v0.69.4 e tags trivy-action e setup-trivy envenenadas a 19 de março de 2026, seguidas de imagens maliciosas no Docker Hub a 22 de março. O código injetado roubou credenciais de runners de CI. A Aqua publicou versões seguras e recomenda fixar as actions a SHA de commit completos.
• Uma análise não é acompanhamento. O Trivy reporta o que encontra quando corre. Manter as conclusões, os responsáveis e o estado entre repositórios e versões, e voltar a verificar o software distribuído à medida que surgem novos avisos, fica a seu cargo.
• A SBOM é inferida a partir de ficheiros. Uma análise anterior ao build lê lockfiles. Quando um repositório não faz commit de nenhum, há pouco para ler, e as versões que uma instalação real resolve são decididas durante o build.
• Amplitude em vez de profundidade. Um só binário cobre muitas tarefas. As equipas que precisam de mais numa área, como infraestrutura como código ou imagens de contentores, mudam muitas vezes essa tarefa para uma ferramenta dedicada.

Cada scanner que o seu pipeline descarrega e executa faz ele próprio parte da sua cadeia de abastecimento de software, a correr ao lado dos segredos do job. No CRACI, é o runner que regista a SBOM, pelo que não há passo de scanner a descarregar para o software que constrói. A política de egress do runner pode limitar os hosts a que qualquer passo do job chega, e o traço de rede de cada job é registado. Fixar as actions a SHA de commit, como a Aqua recomenda, aplica-se também no CRACI.

Alternativas ao Trivy, por tarefa que o Trivy faz por si

• SBOM e vulnerabilidades de dependências do software que constrói: CRACI. Regista a SBOM a partir do build, continua a reavaliá-la e encaminha as conclusões para a equipa responsável.
• Análise de imagens de contentores e sistemas de ficheiros: Grype, o scanner de vulnerabilidades open source da Anchore para imagens de contentores, sistemas de ficheiros e SBOM, com dados EPSS e KEV para priorização. Funciona em conjunto com o Syft para SBOM. Consulte CRACI vs Syft e Grype.
• Infraestrutura como código: o Checkov analisa Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Dockerfiles, Bicep e templates ARM, e verifica também segredos e pacotes open source. O KICS cobre Terraform, Kubernetes, Docker, CloudFormation, Ansible, Helm, Pulumi e mais. Ambos são open source sob Apache-2.0.
• Segredos: o Gitleaks deteta palavras-passe, chaves de API e tokens em repositórios Git e ficheiros, e é open source sob MIT.
• Um scanner comercial com conselhos de correção: consulte CRACI vs Snyk e a comparação de ferramentas de SCA.

Para cada opção em mais detalhe, e para Grype vs Trivy, consulte o guia completo de alternativas ao Trivy.

O que o Trivy faz bem

A descrição do próprio Trivy é "a comprehensive and versatile security scanner", e é exata. Um só binário cobre várias tarefas que de outro modo precisariam de ferramentas separadas:

• Muitos alvos. Imagens de contentores, sistemas de ficheiros, repositórios Git remotos, imagens de máquinas virtuais e Kubernetes.
• Muitos scanners. Pacotes do sistema operativo e dependências de software, vulnerabilidades conhecidas, configurações incorretas de infraestrutura como código, segredos e licenças de software.
• SBOM à entrada e à saída. trivy fs --format cyclonedx ou --format spdx-json escreve uma SBOM, e trivy sbom analisa uma SBOM existente em busca de vulnerabilidades.
• Corre em qualquer lado. É open source sob Apache-2.0, funciona como CLI e tem uma GitHub Action e um operador Kubernetes.

O CRACI não faz nenhuma análise de IaC, de segredos ou de clusters. Se precisa de verificar um plano Terraform, apanhar um token que entrou num commit ou analisar uma imagem de terceiros que não construiu, o Trivy ou uma das ferramentas acima é a escolha certa.

2:07

Onde o CRACI é diferente

O Trivy lê ficheiros; o CRACI observa o build

A documentação do Trivy é clara quanto ao seu método: "If the target is a pre-build project, like a code repository, Trivy will analyze files used for building, such as lock files." Para um alvo posterior ao build, como uma imagem de contentor, lê antes metadados de pacotes instalados e binários. Em repositórios Node.js, isso significa package-lock.json, yarn.lock, pnpm-lock.yaml ou bun.lock.

Essa conceção é razoável, e tem um limite previsível. expressjs/express 5.2.1 não faz commit de nenhum lockfile, e o repositório anthropics/claude-code não tem qualquer manifesto de dependências, pelo que, numa análise anterior ao build de qualquer um deles, o Trivy não tem nada para ler. Isso é o Trivy a funcionar como documentado, não a falhar. As versões que uma instalação real resolveria são decididas durante o build.

O CRACI começa pela outra ponta. Os jobs correm com runs-on: craci, e um proxy que reconhece pacotes regista o que o job obtém de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, bem como predefinições de descarga. Os pacotes restaurados de uma cache de CI levam consigo as suas evidências. A SBOM (CycloneDX ou SPDX) descreve o que o build realmente usou, com ou sem lockfile.

Indica quando o registo está incompleto

Cada job e cache do CRACI tem um estado de completude: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Uma SBOM vazia ou escassa é visível como tal, em vez de parecer igual à de um projeto com poucas dependências.

Controla o build

Como o CRACI executa o job, pode aplicar uma política de egress de rede: negação ou permissão por defeito, com 24 predefinições integradas de fontes de software, validada antes de o job arrancar e com falha em modo fechado. O controlo de egress está fora do âmbito do Trivy. A API devolve SBOM, traços de rede e proveniência. O CRACI não assina a proveniência. Para a assinatura, a documentação do Trivy mostra um fluxo com duas ferramentas: o Trivy escreve a SBOM e o Cosign assina-a como atestação.

Continua a vigiar

O Trivy analisa quando o executa. O CRACI agrega vulnerabilidades de todos os builds e repositórios e continua a reavaliar as SBOM monitorizadas, e as equipas de segurança podem fazer a triagem das conclusões e encaminhá-las para a equipa responsável pela correção. As SBOM de fornecedores são monitorizadas a par dos seus próprios builds. Os policy gates do CRACI podem bloquear um build; os alertas por limiar estão no roadmap.

Um inventário do que está implementado e onde

A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global. Quando surge uma nova vulnerabilidade, pode ver que produtos executam a versão afetada, em vez de o reconstituir a partir de notas de lançamento e folhas de cálculo.

Migrar do Trivy

No CRACI não há SBOM a gerar nem análise de dependências a manter para os builds que distribui. O runner regista a SBOM enquanto o build corre, e o CRACI continua a verificá-la face a novas vulnerabilidades depois de o build terminar.

Tenha bem presente o que o CRACI não faz. Não analisa infraestrutura como código, clusters Kubernetes nem imagens de máquinas virtuais, não procura segredos nem configurações incorretas, e não analisa imagens ou software que não construiu. Os alertas por limiar estão no roadmap. Hoje executa apenas GitHub Actions, com GitLab CI e Jenkins no roadmap. Se depende do Trivy para alguma destas coisas, mantenha-o para isso.

Para o Cyber Resilience Act

O CRA pede aos fabricantes que documentem os componentes de cada produto, incluindo uma SBOM, e que tratem e reportem as vulnerabilidades no que distribuem. O Trivy ajuda ao encontrar vulnerabilidades e configurações incorretas e ao produzir SBOM, e a cadeia de evidências da versão à SBOM cabe-lhe a si construir. O CRACI regista a SBOM por build, liga-a ao artefacto, exporta SBOM em CycloneDX ou SPDX e submete as notificações de vulnerabilidades do CRA em seu nome. Automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de software de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA. Consulte o que é o CRA e a geração de SBOM durante o build.

CRACI vs Trivy: perguntas frequentes

Opções gratuitas, o comprometimento de março de 2026 e o que o CRACI substitui

Qual é a melhor alternativa ao Trivy?

Depende da função do Trivy que está a substituir. Para SBOM e vulnerabilidades de dependências no software que constrói com GitHub Actions, o CRACI regista a SBOM a partir do build e continua a acompanhá-la. Para analisar imagens de contentores, o Grype é um equivalente open source próximo. Para infraestrutura como código, o Checkov e o KICS são opções open source. Para segredos, o Gitleaks. Nenhuma ferramenta substitui sozinha todo o Trivy.

Existe uma alternativa gratuita ao Trivy?

Sim. O Grype (imagens, sistemas de ficheiros e SBOM), o Checkov e o KICS (infraestrutura como código) são open source sob Apache-2.0, e o Gitleaks (segredos) é open source sob MIT. O CRACI é um produto pago, faturado por minuto de build, sem mensalidade.

O Trivy continua a ser seguro depois do comprometimento de março de 2026?

O aviso de segurança da Aqua Security (CVE-2026-33634) descreve uma versão maliciosa do Trivy v0.69.4 e tags trivy-action e setup-trivy envenenadas a 19 de março de 2026, e imagens maliciosas no Docker Hub a 22 de março. A Aqua lista versões seguras e recomenda rodar os segredos que possam ter sido expostos e fixar as GitHub Actions a SHA de commit completos. Consulte o aviso para as versões que utiliza.

Qual é a diferença entre o Trivy e o Grype?

Ambos são scanners open source sob Apache-2.0. O Grype foca-se em vulnerabilidades em imagens de contentores, sistemas de ficheiros e SBOM, e funciona em conjunto com o Syft para gerar SBOM. O Trivy cobre mais alvos e scanners num só binário, incluindo infraestrutura como código, segredos, licenças, imagens de máquinas virtuais e Kubernetes.

O CRACI pode substituir o Trivy?

Para a SBOM e as vulnerabilidades de dependências do software que constrói em GitHub Actions, sim: o CRACI regista a SBOM enquanto o build corre e continua a reavaliá-la face a dados de vulnerabilidades. O CRACI não analisa infraestrutura como código, clusters Kubernetes, imagens de máquinas virtuais, segredos, configurações incorretas nem imagens que não construiu. Mantenha o Trivy, ou outro scanner, para esses casos.

O CRACI analisa Terraform ou outra infraestrutura como código?

Não. O CRACI regista o que os seus builds obtêm e acompanha as vulnerabilidades no que distribui. Para Terraform e outra infraestrutura como código, use o scanner de configurações incorretas do Trivy ou uma ferramenta dedicada como o Checkov ou o KICS.