CRACI vs Dependency-Track

O que o Dependency-Track faz bem

O OWASP Dependency-Track é uma escolha forte para a análise de componentes. É open source sob a licença Apache 2.0, acompanha a utilização de componentes em todas as versões de todas as aplicações do seu portefólio e obtém informação sobre vulnerabilidades de várias fontes, incluindo a National Vulnerability Database e os GitHub Advisories. O seu motor de políticas abrange regras de segurança, de licenças e operacionais, e consome e produz documentos CycloneDX VEX. A sua conceção API-first adequa-se ao CI/CD: os pipelines carregam SBOM para /api/v1/bom.

As equipas de setores regulados gostam dele por ser transparente, self-hosted e construído em torno de um formato normalizado. O seu ponto fraco não é a análise. É o que entra nela.

A análise depende daquilo que recebe

O Dependency-Track consome SBOM; não as gera. Todas as conclusões, violações de políticas e vistas de portefólio dependem da SBOM que o seu pipeline envia. Se a SBOM omitir uma dependência, o Dependency-Track não a consegue assinalar. Se dois geradores discordarem, o Dependency-Track mostra aquele que carregou.

Na prática, os geradores de SBOM discordam muito, e as razões estão na sua própria documentação:

• Nenhum ponto em comum. Cada gerador decide por si o que conta como componente e em que ficheiros confiar, pelo que dois deles, apontados ao mesmo repositório, devolvem listas sobrepostas mas diferentes.
• Falhar o óbvio. Uma ferramenta que resolve dependências a partir de lockfiles não tem nada para resolver num repositório que não os inclui, como é o caso do express 5.2.1. Pode ainda assim devolver uma lista, feita de tudo o resto que reconhece, como GitHub Actions e ficheiros de workflow.
• Oscilações de configuração. O Syft escolhe os seus catalogers consoante o tipo de análise, pelo que uma flag altera o que a mesma ferramenta, na mesma versão, reporta a partir do mesmo checkout.
• Sem manifesto, sem SBOM. Um repositório sem qualquer manifesto de dependências não dá a um scanner baseado em ficheiros nada com que trabalhar, e o que cada ferramenta devolve nesse caso diz mais sobre a ferramenta do que sobre o projeto.
• Metadados escassos. A maioria dos geradores não tem fonte para o campo de fornecedor da NTIA, pelo que este sai vazio, seja qual for o conteúdo do repositório.

O CRACI não pode ser comparado desta forma. Regista builds em vez de analisar um diretório, pelo que não pode ser executado da mesma maneira. A questão não é que alguma destas ferramentas seja má. É que uma análise estática de um repositório é uma estimativa do que um build irá usar, e a estimativa varia com a ferramenta, as suas definições e os ficheiros presentes.

O que o CRACI muda na origem

A SBOM vem do build

O CRACI é um runner compatível com GitHub Actions. Muda runs-on para craci e os seus jobs correm no CRACI em máquinas virtuais isoladas. Durante cada job, um proxy que reconhece pacotes regista o tráfego para as origens de pacotes: origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de transferência. A evidência das dependências acompanha as caches de CI, pelo que um pacote restaurado de uma cache continua no registo. A SBOM, em CycloneDX ou SPDX, inclui todas as dependências transitivas que o build realmente usou.

Indica quando está incompleta

Cada SBOM do CRACI inclui um estado de completude por job e por cache: Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. Sabe se cada SBOM é um registo integral ou se tem uma lacuna. Isso importa quando um auditor pergunta como sabe que o seu inventário está completo.

Regista a SBOM dentro do build

O CRACI gera a SBOM dentro do seu próprio runner, a partir do que o job obteve. A API devolve SBOM, traços de rede e proveniência.

Controla o que o build pode alcançar

Como o CRACI executa o job, pode impor uma política de egress de rede: negação ou permissão por defeito, com 24 predefinições integradas de origens de software e origens personalizadas tipadas. As políticas são validadas antes de o job começar e falham em modo fechado. O Dependency-Track pode dizer-lhe a posteriori que um componente tem risco; uma política de egress limita, à partida, as origens de onde um build pode obter pacotes.

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 versão e folhas de cálculo.

Substituir o Dependency-Track pelo CRACI

O CRACI cobre as duas metades do trabalho que antes exigiam um gerador e o Dependency-Track. Produz a SBOM no build, continua a reavaliar as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, agrega as conclusões entre builds e repositórios e permite que as equipas de segurança façam a sua triagem e encaminhem cada uma para a equipa responsável pela correção. Não há passo de carregamento para manter nem servidor para operar.

Tenha bem presente aquilo de que abdica. O motor de políticas do Dependency-Track é maduro. O CRACI tem políticas que bloqueiam builds e política de licenças, enquanto os comentários e os alertas por limiar estão no roadmap. O Dependency-Track é também open source e self-hosted, ao passo que o CRACI é hoje um serviço gerido, com runners alojados pelo cliente no roadmap para o Enterprise. Se isso lhe importar mais do que a qualidade do inventário, mantenha o Dependency-Track.

Porque é que isto importa em setores regulados

Ao abrigo do Cyber Resilience Act da UE, os fabricantes têm de saber o que está em cada versão do produto e tratar as vulnerabilidades nela presentes, com obrigações de notificação de vulnerabilidades ativamente exploradas a partir de setembro de 2026. Uma vulnerabilidade que não consegue ver porque a sua SBOM omitiu o componente continua a ser a sua vulnerabilidade.

O CRACI 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, e exporta SBOM em CycloneDX ou SPDX, incluindo vulnerabilidades. O inventário e a monitorização vêm do mesmo registo daquilo a partir do qual cada versão foi compilada. Consulte conformidade com o CRA, IoT industrial e telecomunicações.