Melhores ferramentas de SBOM em 2026

A resposta curta

• SBOM gratuitas para imagens de contentor e sistemas de ficheiros: Syft, ou Trivy se também quiser um scanner de vulnerabilidades, segredos e IaC.
• CycloneDX a partir do código-fonte: cdxgen, da comunidade CycloneDX.
• SPDX para uma saída de build que já empacota: o Microsoft SBOM Tool.
• Cargas de trabalho na AWS: o Amazon Inspector SBOM Generator, que alimenta o Amazon Inspector.
• Uma SBOM rápida de um repositório GitHub: a exportação do grafo de dependências do GitHub.
• Um local gratuito e de alojamento próprio para monitorizar SBOM: OWASP Dependency-Track.
• Primeiro a conformidade de licenças: FOSSA. SBOM de fornecedores e de portefólio: Manifest ou Cybeats. Frotas de contentores e pacotes de políticas governamentais: Anchore Enterprise.
• Uma SBOM do que os seus próprios builds realmente trouxeram, com monitorização de vulnerabilidades e dados de proveniência: CRACI, para GitHub Actions.

O que faz uma ferramenta de SBOM

Uma lista de materiais de software enumera os componentes, bibliotecas e dependências de um software, num formato legível por máquina como CycloneDX ou SPDX. As ferramentas de SBOM são de dois tipos. Os geradores escrevem a SBOM. Os gestores guardam SBOM de muitos produtos e fornecedores, cruzam-nas com dados de vulnerabilidades, aplicam políticas e partilham-nas. Os gestores dependem daquilo que os geradores lhes fornecem.

O momento em que a SBOM é obtida importa tanto como a ferramenta que a obtém. As orientações da CISA sobre tipos de SBOM distinguem uma SBOM de código-fonte, criada a partir do ambiente de desenvolvimento e dos ficheiros de código-fonte, uma SBOM de build, gerada como parte da compilação do artefacto a lançar, e uma SBOM analisada, gerada através da análise de artefactos, como executáveis e imagens de contentor, após o build. A maioria dos geradores abaixo produz SBOM de código-fonte ou analisadas. O CRACI produz uma SBOM de build. SBOM durante o build explica a diferença em pormenor.

A quem se destina

Esta página destina-se às equipas que precisam de SBOM, para o Cyber Resilience Act, para um questionário de um cliente ou para a sua própria gestão de vulnerabilidades, e que estão a avaliar as opções. Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta. Cada afirmação sobre outra ferramenta vem da sua própria documentação, e cada ferramenta tem uma página CRACI vs X mais longa.

Como escolher uma ferramenta de SBOM

• Precisa de produzir SBOM, de as gerir, ou de ambas as coisas? Um gerador dá-lhe um ficheiro. Um gestor dá-lhe um local para guardar ficheiros de muitos produtos e fornecedores, enriquecê-los e agir sobre eles.
• O software é seu ou comprado? Nos seus próprios builds controla a entrada, pelo que a pode registar. No software de fornecedores precisa de receção, validação e, por vezes, análise de binários.
• Até que ponto precisa de ter a certeza de que a lista está completa? Os geradores leem ficheiros a posteriori, e discordam mais do que a maioria das pessoas espera (ver abaixo). Uma SBOM de build descreve o que o build usou.
• Que formato pedem os seus clientes? O CycloneDX e o SPDX são ambos amplamente aceites; a maioria das ferramentas escreve pelo menos um deles.
• Que CI utiliza, e tem de ser de alojamento próprio? Os geradores open source funcionam em qualquer lado. O CRACI suporta hoje GitHub Actions em Linux, como serviço gerido, com GitLab CI, Jenkins e runners alojados pelo cliente no roadmap.

Geradores de SBOM

Esta comparação mostra o que cada gerador faz, não quantos componentes devolve.

CRACI

O CRACI é um registador e não um scanner. Os seus jobs de GitHub Actions são executados em runners do CRACI, e um proxy que reconhece pacotes regista o que cada job obtém, incluindo pacotes restaurados de uma cache de CI. A SBOM, em CycloneDX ou SPDX, inclui as dependências transitivas que o build usou e indica a sua completude por job e por cache. Depois, o CRACI continua a reavaliar as SBOM monitorizadas, pelo que faz o trabalho de um gerador e de um gestor em conjunto. Ideal para software que compila em GitHub Actions. A ter em conta: não consegue analisar uma imagem ou um diretório, e hoje executa jobs Linux em GitHub Actions (outros sistemas de CI, Windows e macOS estão no roadmap). Geração de SBOM no CRACI

Syft

O Syft é o gerador gratuito da Anchore, sob Apache-2.0, para imagens de contentor e sistemas de ficheiros. Reconhece dezenas de tipos de pacotes, escreve CycloneDX, SPDX e Syft JSON, e pode criar atestações SBOM in-toto assinadas. O Grype, o seu complemento, cruza a SBOM com vulnerabilidades. Ideal para imagens e para qualquer pipeline que precise de um gerador gratuito. A ter em conta: os catalogadores são escolhidos pelo tipo de análise, pelo que, num checkout do express com pacotes instalados, uma única flag decide se os pacotes npm aparecem sequer no resultado. CRACI vs Syft e Grype

Trivy

O Trivy, da Aqua Security, é um scanner versátil sob Apache-2.0 para imagens, sistemas de ficheiros, repositórios, imagens de VM e Kubernetes. Encontra vulnerabilidades, configurações incorretas de IaC, segredos e licenças, e escreve CycloneDX ou SPDX como efeito secundário. Ideal para equipas que querem um único binário gratuito para muitas verificações de segurança. A ter em conta: num repositório, lê lockfiles, pelo que o express 5.2.1 (sem lockfile) e o claude-code (sem manifesto) não lhe dão nada para ler, exatamente como está documentado. CRACI vs Trivy

cdxgen

O cdxgen é um projeto OWASP CycloneDX que cria BOM CycloneDX a partir de código-fonte e imagens de contentor, sob Apache-2.0. Ideal para equipas normalizadas em CycloneDX que querem um gerador da própria comunidade do formato. A ter em conta: tal como os outros scanners, só consegue reportar o que os ficheiros à sua frente declaram. CRACI vs uma stack de SBOM DIY

Microsoft SBOM Tool

O Microsoft SBOM Tool é um gerador com licença MIT que escreve SPDX 2.2, ou SPDX 3.0 a pedido, e pode validar uma SBOM face à especificação SPDX. Espera uma pasta build drop, um nome de pacote, uma versão e um fornecedor na linha de comandos, o que o torna um passo pós-build, e funciona em GitHub Actions e Azure Pipelines. Ideal para equipas que querem SPDX para uma saída de build que já empacotam. A ter em conta: apontado a repositórios tal como estão no commit, e não a um build drop, quase nada tem para descrever. Como recebe um fornecedor na linha de comandos, consegue preencher o campo do fornecedor. CRACI vs uma stack de SBOM DIY

Exportação do grafo de dependências do GitHub

O grafo de dependências do GitHub resume os manifestos e os lockfiles de um repositório, além de tudo o que for enviado através da dependency submission API, e exporta em SPDX a partir da interface ou da REST API. Alimenta os alertas do Dependabot e está incluído em todos os planos do GitHub. Ideal para equipas que já estão no GitHub e precisam de uma SBOM rápida. A ter em conta: reflete o branch predefinido e não um commit fixado, e é construído a partir do que o GitHub sabe sobre o repositório e não a partir de ficheiros lidos por um scanner. CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

O Sbomgen é o gerador por detrás das análises de imagens, Lambda e EC2 do próprio Amazon Inspector, disponibilizado como binário Linux autónomo. Lê metadados de pacotes de imagens de contentor, diretórios, arquivos, volumes montados e binários compilados de Go e Rust, cobre pacotes do sistema operativo (APK, DPKG, RPM) e linguagens como C#, Go, Java, Node.js, PHP, Python, Ruby e Rust, e escreve CycloneDX. Pode enviar a SBOM para a Amazon Inspector Scan API para obter conclusões de vulnerabilidades, o que exige uma conta AWS. Ideal para equipas cujas cargas de trabalho já correm na AWS. A ter em conta: funciona apenas em Linux e, tal como os outros scanners, encontra o que os ficheiros que lê declaram.

Safeguard

A CLI do Safeguard executa o Syft e o Grype para produzir SBOM CycloneDX e SPDX a partir de repositórios, imagens de contentor e manifestos carregados, e a sua plataforma acrescenta pull requests de correção escritos por IA e policy gates. Ideal para equipas que querem análise e correções automatizadas numa única subscrição. A ter em conta: tal como os outros scanners, lista o que os ficheiros que lê declaram. CRACI vs Safeguard

De que depende uma SBOM de análise

Aponte os geradores acima ao mesmo repositório e devolverão listas diferentes. Estes são os padrões que a própria documentação das ferramentas prevê:

• As ferramentas discordam sobre o que conta como componente. Cada gerador decide por si em que ficheiros confiar e como dar nome ao que encontra, pelo que um repositório dá a cada um deles uma lista diferente.
• Sem lockfile, sem dependências. O express 5.2.1 não inclui nenhum, pelo que um gerador que resolve dependências a partir de lockfiles não reporta nenhuma das suas dependências npm e devolve o que mais reconhecer.
• Sem qualquer manifesto. O repositório claude-code não tem manifesto nem lockfile, pelo que o que cada ferramenta devolve é montado a partir de outros tipos de ficheiros e diz mais sobre a ferramenta do que sobre o projeto.
• Metadados escassos. O campo do fornecedor fica muitas vezes vazio, porque a maioria dos geradores não tem fonte para ele.

Nenhuma destas ferramentas está avariada. Cada uma lê os ficheiros que tem à frente, como foi concebida. A lição é que uma SBOM de análise depende da ferramenta, das suas definições e de alguém ter instalado as dependências primeiro. Para saber o que o Syft, o Trivy e o cdxgen leem, consulte o que escapa aos geradores de SBOM open source.

Gestores de SBOM

Anchore Enterprise

O Anchore Enterprise assenta no Syft e no Grype e acrescenta aquilo de que as grandes organizações precisam: SBOM de contentores, código-fonte e sistemas de ficheiros, SBOM importadas validadas quanto à correção do esquema, nova análise contínua sem o artefacto original e pacotes de políticas para FedRAMP, NIST, CIS, PCI DSS e CMMC. É implementado em Kubernetes, Docker Compose ou air-gapped. Ideal para frotas de contentores em vários sistemas de CI e para trabalho governamental. A ter em conta: as suas SBOM continuam a descrever o que um scanner encontrou, e o preço é sob orçamento. CRACI vs Anchore

FOSSA

O FOSSA começou pela conformidade de licenças: deteção de licenças em texto integral, políticas e avisos de atribuição. Gera e importa SBOM SPDX e CycloneDX, pode acrescentar declarações VDR ou VEX, verifica as importações face aos elementos mínimos da NTIA e da FDA, e partilha SBOM através de um portal no plano Enterprise. O plano Free cobre 5 projetos. Ideal para equipas cuja primeira preocupação é o risco de licenças. A ter em conta: a sua CLI consulta as suas ferramentas de build quando existe um build funcional e faz inferências a partir do código-fonte quando não existe, e a análise de binários e de excertos são extras. CRACI vs FOSSA

Cybeats SBOM Studio

O SBOM Studio chama a si próprio "the SBOM system of record." Importa e exporta SPDX 2.2 a 3.0.1 e CycloneDX 1.2 a 1.7, pontua a qualidade da SBOM antes da importação, cruza continuamente cada componente e partilha dados de SBOM e VEX com clientes, incluindo através da Transparency Exchange API. Ideal para equipas de segurança de produto em ICS, dispositivos médicos, telecomunicações e automóvel que gerem um programa de SBOM. A ter em conta: gere SBOM em vez de as produzir, e uma pontuação de qualidade confirma o formato, não o que escapou ao gerador. CRACI vs Cybeats e alternativas ao Cybeats

Manifest

O Manifest recolhe, enriquece e partilha SBOM entre os seus produtos, os seus fornecedores e os seus modelos de IA. Os fornecedores carregam-nas através de um portal seguro e, quando não fornecem nenhuma, o Manifest pode analisar o binário e gerar uma. Suporta SPDX, CycloneDX e VEX e faz o mapeamento para as orientações da FDA, o NIST 800-218 e o UNECE R155. Ideal para organizações cuja principal exposição é o software que compram. A ter em conta: a sua GitHub Action gera as SBOM do software próprio com o Syft por defeito. CRACI vs Manifest

OWASP Dependency-Track

O Dependency-Track é uma plataforma sob Apache 2.0 que acompanha componentes em todas as versões de todas as aplicações, obtém dados de vulnerabilidades de fontes como a NVD e os GitHub Advisories, aplica políticas de segurança, de licenças e operacionais, e consome e produz CycloneDX VEX. Os pipelines carregam SBOM através da sua API. Ideal para equipas que querem uma plataforma de análise transparente e de alojamento próprio. A ter em conta: não gera SBOM, e é a sua equipa que a executa (o servidor da API precisa de pelo menos 2 GB de RAM e 2 núcleos de CPU). CRACI para utilizadores do Dependency-Track

CycloneDX ou SPDX

Ambos os formatos são normas abertas, e a maioria das ferramentas desta página escreve pelo menos um deles. O CycloneDX é um projeto da OWASP, normalizado pela Ecma International como ECMA-424, e transporta dados de vulnerabilidades e VEX juntamente com a lista de componentes. O SPDX é um projeto da Linux Foundation e uma norma internacional, ISO/IEC 5962:2021. O Cyber Resilience Act pede "um formato de uso corrente e legível por máquina" sem nomear nenhum, por isso escolha o formato que os seus clientes e as suas ferramentas a jusante leem. Consulte os exemplos de SBOM para ver ambos lado a lado, e as boas práticas de SBOM para saber como os gerir. Para guardar e monitorizar SBOM em escala, consulte gestão de SBOM.

Como o CRACI se enquadra

O CRACI não é um scanner nem um gestor. É um registador. Os seus jobs de GitHub Actions são executados em runners do CRACI (mude runs-on para craci), e um proxy que reconhece pacotes regista o que cada job obtém de fontes npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga. Os pacotes restaurados de uma cache de CI mantêm as suas evidências. A SBOM, em CycloneDX ou SPDX, inclui as dependências transitivas que o build usou e indica a sua completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global.

Depois do build, o CRACI continua a reavaliar as SBOM monitorizadas, agrega vulnerabilidades de todos os builds e repositórios, suporta VEX, devolve SBOM, traços de rede e proveniência através da sua API e exporta SBOM como ficheiros CycloneDX ou SPDX. É possível adicionar SBOM de fornecedores, pelo que os componentes comprados são monitorizados juntamente com os seus próprios builds. Automatiza uma parte significativa da visibilidade da cadeia de abastecimento de software e das evidências de que as empresas precisam para o seu processo mais amplo de conformidade com o CRA. Consulte geração de SBOM no CRACI para conhecer a funcionalidade completa.

Assim, o CRACI faz o trabalho de um gerador e de um gestor em conjunto, para o software que compila. Não é a escolha certa quando:

• precisa de SBOM de imagens ou de software que não compilou (use um gerador como o Syft ou o Trivy),
• precisa de um motor de políticas maduro com muitos tipos de regras para um portefólio de produtos e fornecedores (use um gestor),
• os seus pipelines funcionam fora do GitHub Actions, em Windows ou macOS, ou têm de ser de alojamento próprio (tudo isto no roadmap do CRACI).

A forma mais rápida de avaliar é lado a lado: marque uma demo, execute um dos seus workflows no CRACI e coloque a SBOM dele ao lado da que a sua ferramenta atual produz.

Consulte também ferramentas de SCA comparadas, SBOM geradas por IA vs SBOM durante o build e porque é que as SBOM geradas durante o build diferem das analisadas.

Ferramentas de SBOM: perguntas frequentes

O que é uma ferramenta de SBOM?

Uma ferramenta de SBOM produz ou gere uma lista de materiais de software: uma lista legível por máquina dos componentes, bibliotecas e dependências de um software. Geradores como o Syft, o Trivy e o cdxgen escrevem a SBOM lendo ficheiros. Gestores como o Dependency-Track, o FOSSA e o Anchore Enterprise guardam SBOM, cruzam-nas com dados de vulnerabilidades e partilham-nas. O CRACI regista a SBOM durante o próprio build e monitoriza-a depois.

Qual é a melhor ferramenta de SBOM gratuita?

Depende daquilo para que a aponta. O Syft e o Trivy são geradores gratuitos, sob Apache-2.0, para imagens de contentor e sistemas de ficheiros. O cdxgen escreve CycloneDX a partir do código-fonte e de imagens. O Microsoft SBOM Tool escreve SPDX para uma pasta de saída do build. O OWASP Dependency-Track é um gestor gratuito e de alojamento próprio para as SBOM que essas ferramentas produzem.

Devo usar o Syft ou o Trivy?

O Syft foca-se na geração de SBOM e combina com o Grype para a correspondência de vulnerabilidades. O Trivy é um scanner mais amplo que também encontra configurações incorretas de IaC, segredos e licenças, e escreve CycloneDX ou SPDX pelo caminho. Ambos leem os ficheiros que têm à frente, pelo que ambos dependem da presença de lockfiles ou de pacotes instalados.

CycloneDX ou SPDX: que formato de SBOM devo usar?

Ambos são normas abertas e amplamente suportadas. O CycloneDX é um projeto da OWASP, normalizado pela Ecma International como ECMA-424, e transporta também dados de vulnerabilidades e VEX. O SPDX é um projeto da Linux Foundation e uma norma internacional, ISO/IEC 5962:2021. Use aquele que os seus clientes e as suas ferramentas a jusante pedirem; a maioria dos geradores escreve ambos.

Porque é que as ferramentas de SBOM dão resultados diferentes para o mesmo projeto?

Cada gerador decide em que ficheiros confiar e o que conta como componente. Uns leem lockfiles, outros leem pacotes instalados, outros leem binários, e um repositório sem lockfile não dá nada com que trabalhar a um leitor de lockfiles. Uma SBOM de análise depende da ferramenta, das suas definições e de as dependências terem sido instaladas antes da análise. Uma SBOM gerada durante o build evita isso, registando o que o build realmente obteve.

O Cyber Resilience Act exige uma ferramenta ou um formato de SBOM específico?

Não. O Anexo I, parte II, do CRA exige que os fabricantes elaborem uma lista de materiais de software num formato de uso corrente e legível por máquina, que abranja, no mínimo, as dependências de nível superior dos produtos. Tanto o CycloneDX como o SPDX cumprem este requisito. O regulamento não menciona nenhuma ferramenta.

O CRACI pode gerar uma SBOM para software que não compilei?

Não. O CRACI regista os builds executados nos seus runners, pelo que as suas SBOM descrevem software que compila. Para software que compra, pode adicionar a SBOM do fornecedor ao CRACI e monitorizá-la juntamente com os seus próprios builds. Para uma imagem de contentor de terceiros que não compilou, um scanner como o Syft ou o Trivy é a escolha prática.

Que sistemas de CI suporta o CRACI?

GitHub Actions hoje, em runners Linux x86-64 e ARM64. Muda runs-on para craci e as execuções continuam a aparecer no GitHub. Outros sistemas de CI, a começar pelo GitLab CI e pelo Jenkins, estão no roadmap.