Alternativas ao Dependency-Track

Somos nós que desenvolvemos o CRACI, por isso tenha isso em conta; descrevemos cada opção a partir da sua própria documentação e dizemos quando outra ferramenta se adequa melhor.

Porque é que as equipas procuram alternativas

O OWASP Dependency-Track é open source sob a licença Apache 2.0. Acompanha a utilização de componentes em cada versão de cada aplicação de um portefólio, obtém informação sobre vulnerabilidades de fontes como a National Vulnerability Database 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 API do Dependency-Track. Para muitas equipas é a resposta certa, e não tem custos de licença.

As razões pelas quais as equipas procuram mais longe têm normalmente a ver com âmbito e adequação:

• Prefere não o operar. O Dependency-Track é self-hosted, pelo que o servidor, as atualizações e as cópias de segurança ficam a seu cargo.
• Precisa de workflows para fornecedores. Recolher SBOM de fornecedores, analisar binários de fornecedores ou partilhar SBOM com clientes são tarefas em torno das quais algumas plataformas comerciais são construídas.
• Precisa de conformidade de licenças com resultados jurídicos, como avisos de atribuição.
• Não confia nos dados de entrada. O Dependency-Track analisa as SBOM que recebe; não as gera. Se o gerador deixar escapar uma dependência, o mesmo acontece em todas as conclusões a jusante.

O que procurar

• De onde vem a SBOM: gerada pela plataforma, importada ou registada a partir do build.
• Se algo lhe indica quão completa é uma SBOM.
• Workflows de VEX, triagem e políticas, se a sua equipa de segurança trabalha hoje neles.
• Análise de licenças e atribuição.
• Quem a opera, e se pode ser self-hosted ou correr em modo air-gapped.
• Receção de SBOM de fornecedores e partilha com clientes ou autoridades.

As opções

CRACI (o nosso produto)

O CRACI não é uma plataforma de análise de portefólio. É um runner compatível com GitHub Actions: altera runs-on para craci, e um proxy que reconhece pacotes regista o que cada job obtém das fontes de pacotes, incluindo pacotes restaurados de caches de CI. A SBOM, em CycloneDX ou SPDX, vem desse registo, com um estado de completude por job e por cache. O CRACI monitoriza essas SBOM face a novas vulnerabilidades, e a API devolve SBOM, traços de rede e proveniência. A vista de inventário do CRACI mostra exatamente que versões de software estão implementadas em que produtos, a nível global.

Indicado para: equipas em GitHub Actions cujo problema são os dados de entrada. O CRACI produz a SBOM no build e monitoriza-a, pelo que não há gerador para executar nem passo de carregamento para manter.

A considerar se: quer evidências do build e controlo do egress na origem. O CRACI permite às equipas de segurança fazer a triagem das conclusões, encaminhá-las para a equipa certa e registar VEX. Os policy gates do CRACI podem bloquear um build, e o CRACI aplica a política de licenças. O CRACI corre hoje apenas em GitHub Actions, com GitLab CI e Jenkins no roadmap.

CRACI para utilizadores do Dependency-Track

Anchore Enterprise

O Anchore Enterprise assenta no Syft e no Grype, open source, da Anchore. Gera SBOM a partir de imagens de contentores, código-fonte e sistemas de ficheiros, importa SBOM criadas noutro lado, volta a analisar SBOM guardadas sem o artefacto original e aplica pacotes de políticas para FedRAMP, NIST, CIS, PCI DSS e CMMC. É implementado em Kubernetes, Docker Compose ou air-gapped, com integrações para GitHub, GitLab, Jenkins, AWS CodeBuild e Azure Pipelines. Os preços são sob orçamento.

Indicado para: frotas de contentores em vários sistemas de CI, e ambientes governamentais ou air-gapped.

A considerar se: quer uma plataforma comercial, mas continuar a operá-la por conta própria. Se só precisa de geração e correspondência, o Syft e o Grype são gratuitos.

CRACI vs Anchore

FOSSA

O FOSSA começou pela conformidade de licenças open source: deteção de licenças por texto integral, políticas automáticas e avisos de atribuição. Produz e consome SBOM em SPDX e CycloneDX, opcionalmente com declarações VDR ou VEX, exige os elementos mínimos da NTIA e da FDA nas SBOM importadas e, no Enterprise, partilha SBOM através de um SBOM Portal. O plano Free funciona como SaaS multi-tenant; o Business custa $20 por projeto por mês, com faturação anual (em setembro de 2026).

Indicado para: equipas em que o risco de licenças e as SBOM de fornecedores são a principal preocupação.

A considerar se: quer uma plataforma alojada e uma forma gratuita de começar.

CRACI vs FOSSA

Cybeats SBOM Studio

O SBOM Studio descreve-se como "the SBOM system of record." Guarda SBOM dos seus produtos e fornecedores, suporta SPDX 2.2 a 3.0.1 e CycloneDX 1.2 a 1.7, valida ficheiros com um SBOM Quality Score, cruza cada componente continuamente com informação sobre vulnerabilidades, trata de VEX e análise de licenças e partilha SBOM com clientes, incluindo através da Transparency Exchange API. Para a geração, a Cybeats remete para o seu Marketplace de fornecedores de ferramentas.

Indicado para: equipas centrais de segurança do produto em ICS e OT, dispositivos médicos, telecomunicações e indústria automóvel.

A considerar se: gere um programa de SBOM em muitos produtos e fornecedores.

CRACI vs Cybeats

Manifest

O Manifest cria, importa, enriquece e partilha SBOM dos seus produtos, do software dos seus fornecedores e dos seus modelos de IA. Os fornecedores carregam SBOM através de um portal e, quando um fornecedor não disponibiliza nenhuma, o Manifest pode gerar uma a partir do binário compilado. Transforma as conclusões em tickets e contactos com fornecedores, suporta VEX, e a respetiva CLI funciona em qualquer CI, com uma GitHub Action que executa o Syft por defeito.

Indicado para: organizações cuja principal exposição é o software que compram.

A considerar se: o risco de terceiros e os inventários de modelos de IA importam tanto como os seus próprios builds.

CRACI vs Manifest

ONEKEY

O ONEKEY é uma plataforma de cibersegurança e conformidade do produto para dispositivos conectados. Carrega uma imagem de firmware, e o ONEKEY analisa o binário, sem precisar do código-fonte, para encontrar componentes, vulnerabilidades conhecidas e prováveis zero-days, como credenciais embutidas no código. Gera uma SBOM a partir do binário, importa SBOM de scanners de código-fonte ou de fornecedores, exporta CycloneDX e SPDX e volta a analisar diariamente o firmware carregado. O seu Compliance Wizard cobre o Cyber Resilience Act, a IEC 62443-4-2, a ETSI EN 303 645 e a Radio Equipment Directive.

Indicado para: fabricantes de dispositivos que precisam de analisar firmware, incluindo blobs de fornecedores que nunca compilaram.

A considerar se: os seus produtos são dispositivos conectados e não serviços web.

CRACI vs ONEKEY

SBOM Observer

O SBOM Observer, da empresa sueca Bitfront AB, importa, normaliza e versiona SBOM, executa verificações de políticas, acompanha vulnerabilidades nos componentes e produz evidências de conformidade. Funciona com SPDX, CycloneDX e VEX, corre como SaaS ou on-premises, opcionalmente air-gapped, e inclui ferramentas gratuitas como uma CLI open source e o visualizador SBOM.link. Em 29 de setembro de 2026, o Business custa cerca de $80 (€69) por utilizador por mês com até 10 projetos, e o Enterprise, para 25 utilizadores ou mais, tem preço sob pedido.

Indicado para: equipas que querem o trabalho do Dependency-Track como serviço gerido, com preços publicados.

A considerar se: o preço por utilizador e os limites de projetos por plano se adequam ao seu portefólio.

sbomify

O sbomify gera SBOM na CI através da sua GitHub Action open source, gere-as ao longo das versões e partilha-as, bem como documentos de conformidade, através de um Trust Center com a sua marca, incluindo pela Transparency Exchange API. Suporta CycloneDX e SPDX e integra-se com o Google OSV e o Dependency-Track para análise. É open source e pode ser self-hosted. Em setembro de 2026, o plano Community é gratuito para 1 produto e 5 componentes, apenas com documentos públicos, e o Business custa $159 por mês com faturação anual.

Indicado para: equipas que precisam de partilhar SBOM com clientes, não apenas de as analisar.

A considerar se: quer manter o Dependency-Track para a análise; o sbomify integra-se com ele.

Lado a lado

"Não indicado" significa que não o encontrámos nas páginas públicas do fornecedor. A tabela cobre o Dependency-Track e as cinco primeiras opções; o ONEKEY, o SBOM Observer e o sbomify estão descritos acima. Todas as plataformas exceto o CRACI analisam SBOM produzidas por outra ferramenta, ou geram-nas com um scanner ou a partir de um binário, pelo que a qualidade desses dados de entrada continua a importar, seja qual for a escolhida.

Dependency-Track vs Dependency-Check

Os nomes são parecidos, e ambos são projetos da OWASP, mas fazem trabalhos diferentes. A própria documentação do Dependency-Track compara-os:

• O que é. O Dependency-Track é uma plataforma. O Dependency-Check é uma biblioteca com uma interface de linha de comandos, plugins de build para ferramentas como Maven e Ant, e um plugin para Jenkins.
• Como funciona. O Dependency-Track parte de uma SBOM, gerada durante o build ou obtida de um fornecedor. O Dependency-Check analisa ficheiros no sistema de ficheiros e extrai evidências com diferentes graus de confiança.
• Correspondência. O Dependency-Track faz correspondências precisas através da NVD e de outras fontes. O Dependency-Check usa correspondência difusa através da NVD.
• Resultados. O Dependency-Track disponibiliza métricas através de uma interface web e de uma API REST, com um workflow de auditoria por projeto e em todo o portefólio. O Dependency-Check escreve um relatório estático em HTML, XML, JSON ou CSV por projeto.

Em suma, o Dependency-Check é um scanner e o Dependency-Track é onde as SBOM são analisadas ao longo do tempo. Nenhum deles regista o que o seu build obteve.

Uma nota sobre o Cyber Resilience Act

Se o CRA é a razão pela qual está a rever as suas ferramentas de SBOM, as obrigações de notificação aplicam-se a partir de 11 de setembro de 2026, com um alerta precoce devido no prazo de 24 horas após tomar conhecimento de uma vulnerabilidade ativamente explorada. Cumprir isso depende de saber que versões contêm o componente afetado, o que depende de a SBOM de cada versão estar correta. A Anchore, o FOSSA, a Cybeats e o Manifest publicam todos material sobre o CRA. O CRACI 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. Nenhuma plataforma desta página torna um produto conforme por si só.

Quando ficar com o Dependency-Track

• Sente-se à vontade para o operar, e uma plataforma gratuita, open source e self-hosted adequa-se à sua política.
• A sua equipa de segurança depende do motor de políticas do Dependency-Track, de VEX e das vistas de portefólio.
• A sua verdadeira lacuna é a qualidade das SBOM. Corrija antes os dados de entrada e mantenha a análise que tem.

Para saber mais sobre os dados de entrada, leia sobre a geração de SBOM durante o build e a conformidade com o CRA.

Alternativas ao Dependency-Track: perguntas frequentes

Respostas curtas às perguntas que as equipas fazem quando comparam

O que é o Dependency-Track?

O OWASP Dependency-Track é uma plataforma gratuita e open source sob Apache 2.0 que analisa SBOM. Acompanha os componentes de cada versão de cada aplicação de um portefólio, cruza-os com fontes de vulnerabilidades como a NVD e os GitHub Advisories, aplica políticas de segurança, de licenças e operacionais, e consome e produz CycloneDX VEX. Não gera SBOM; os pipelines carregam-nas através da API.

O que é o acompanhamento de dependências?

O acompanhamento de dependências consiste em manter um registo dos componentes de terceiros que cada versão do seu software usa e em verificar esse registo continuamente face a dados de vulnerabilidades e a políticas. Quando surge um novo aviso de segurança, indica-lhe que versões contêm o componente afetado. O registo é normalmente uma SBOM por versão.

Como se executa o Dependency-Track?

A sua documentação recomenda o Docker Compose: descarregue o docker-compose.yml de dependencytrack.org e execute docker compose up -d. O servidor de API precisa de pelo menos 2 GB de RAM. Consulte docs.dependencytrack.org para configurações de produção.

Qual é a diferença entre o Dependency-Track e o Dependency-Check?

O Dependency-Track é uma plataforma que analisa SBOM em todo um portefólio e disponibiliza os resultados através de uma interface web e de uma API REST. O OWASP Dependency-Check é uma ferramenta de linha de comandos e um conjunto de plugins de build que analisa ficheiros no disco, os associa a vulnerabilidades com correspondência difusa através da NVD e escreve um relatório estático por projeto.

Existe uma alternativa alojada ao Dependency-Track?

Sim. O FOSSA funciona como SaaS, o SBOM Observer oferece SaaS ou on-premises, e o sbomify tem um serviço cloud com um plano Community gratuito. O CRACI também é gerido, e produz a SBOM a partir do build em vez de esperar por um carregamento.