CRACI vs Dependency-Track

Che cosa fa bene Dependency-Track

OWASP Dependency-Track è un'ottima scelta per l'analisi dei componenti. È open source con licenza Apache 2.0, traccia l'uso dei componenti in ogni versione di ogni applicazione del Suo portafoglio e raccoglie dati sulle vulnerabilità da diverse fonti, tra cui il National Vulnerability Database e GitHub Advisories. Il suo motore di policy copre regole di sicurezza, di licenza e operative, e utilizza e produce documenti CycloneDX VEX. Il suo design API-first si adatta alla CI/CD: le pipeline caricano le SBOM su /api/v1/bom.

Ai team dei settori regolamentati piace perché è trasparente, self-hosted e costruito attorno a un formato standard. Il suo punto debole non è l'analisi. È ciò che riceve in ingresso.

L'analisi dipende dal suo input

Dependency-Track utilizza le SBOM; non le genera. Ogni risultato, violazione di policy e vista di portafoglio dipende dalla SBOM inviata dalla Sua pipeline. Se la SBOM omette una dipendenza, Dependency-Track non può segnalarla. Se due generatori non concordano, Dependency-Track mostra la SBOM che Lei ha caricato.

In pratica, i generatori di SBOM sono spesso in disaccordo, e i motivi si trovano nella loro stessa documentazione:

• Nessuna base comune. Ogni generatore decide da sé che cosa conta come componente e di quali file fidarsi, quindi due generatori puntati sullo stesso repository restituiscono elenchi sovrapposti ma diversi.
• Mancano le cose ovvie. Uno strumento che risolve le dipendenze dai lockfile non ha nulla da risolvere in un repository che non ne include, come express 5.2.1. Può comunque restituire un elenco, fatto di tutto ciò che riconosce, come le GitHub Actions e i file di workflow.
• Oscillazioni di configurazione. Syft sceglie i suoi cataloger in base al tipo di scansione, quindi un flag cambia ciò che lo stesso strumento, nella stessa versione, riporta dallo stesso checkout.
• Nessun manifest, nessuna SBOM. Un repository senza alcun manifest di dipendenze non offre a uno scanner basato su file nulla su cui lavorare, e ciò che ogni strumento restituisce dice allora più sullo strumento che sul progetto.
• Metadati scarni. La maggior parte dei generatori non ha una fonte per il campo supplier NTIA, quindi resta vuoto qualunque cosa contenga il repository.

CRACI non può essere confrontato in questo modo. Registra le build anziché scansionare una directory, quindi non può essere eseguito allo stesso modo. Il punto non è che uno di questi strumenti sia scadente. È che una scansione statica di un repository è una stima di ciò che una build userà, e la stima varia con lo strumento, le sue impostazioni e i file presenti.

Che cosa cambia CRACI alla fonte

La SBOM viene dalla build

CRACI è un runner compatibile con GitHub Actions. Lei cambia runs-on in craci e i Suoi job girano su CRACI in macchine virtuali isolate. Durante ogni job, un proxy che riconosce i pacchetti registra il traffico verso le sorgenti di pacchetti: sorgenti npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, oltre ai preset di download. Le evidenze sulle dipendenze viaggiano con le cache CI, così un pacchetto ripristinato da una cache resta nel record. La SBOM, in CycloneDX o SPDX, include tutte le dipendenze transitive effettivamente usate dalla build.

Le dice quando è incompleta

Ogni SBOM di CRACI riporta uno stato di completezza per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Lei sa se ogni SBOM è un record completo o presenta una lacuna. Questo conta quando un auditor chiede come fa a sapere che il Suo inventario è completo.

Registra la SBOM all'interno della build

CRACI genera la SBOM all'interno del proprio runner, a partire da ciò che il job ha scaricato. L'API restituisce SBOM, tracce di rete e provenance.

Controlla ciò che la build può raggiungere

Poiché CRACI esegue il job, può applicare una policy di egress di rete: negazione o autorizzazione predefinita, con 24 preset integrati per le sorgenti software e sorgenti personalizzate tipizzate. Le policy vengono convalidate prima dell'avvio del job e operano in modalità fail closed. Dependency-Track può dirLe a posteriori che un componente è rischioso; una policy di egress limita fin dall'inizio le sorgenti da cui una build può scaricare.

Un inventario di ciò che è distribuito e dove

La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale. Quando emerge una nuova vulnerabilità, può vedere quali prodotti eseguono la versione colpita invece di ricostruirlo da note di rilascio e fogli di calcolo.

Sostituire Dependency-Track con CRACI

CRACI copre entrambe le metà del lavoro che prima richiedeva un generatore e Dependency-Track. Produce la SBOM nella build, continua a rivalutare le SBOM monitorate man mano che vengono pubblicate nuove vulnerabilità, aggrega i risultati tra build e repository e consente ai team di sicurezza di esaminarli e assegnare ciascuno al team responsabile della correzione. Non c'è alcuno step di caricamento da mantenere né alcun server da gestire.

Sia consapevole di ciò a cui rinuncia. Il motore di policy di Dependency-Track è maturo. CRACI ha policy gate che bloccano le build e la policy sulle licenze, mentre commenti e avvisi a soglia sono in roadmap. Dependency-Track è inoltre open source e self-hosted, mentre oggi CRACI è un servizio gestito, con i runner ospitati dal cliente in roadmap per Enterprise. Se questi aspetti contano più della qualità dell'inventario, mantenga Dependency-Track.

Perché conta nei settori regolamentati

Ai sensi del Cyber Resilience Act dell'UE, i fabbricanti devono sapere che cosa contiene ogni release di prodotto e gestirne le vulnerabilità, con obblighi di segnalazione per le vulnerabilità attivamente sfruttate a partire da settembre 2026. Una vulnerabilità che non può vedere perché la Sua SBOM ha omesso il componente resta comunque una Sua vulnerabilità.

CRACI automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui le aziende hanno bisogno per il loro più ampio processo di conformità al CRA, ed esporta SBOM in CycloneDX o SPDX, vulnerabilità incluse. L'inventario e il monitoraggio provengono dallo stesso record di ciò con cui è stata compilata ogni release. Veda la conformità al CRA, l'IoT industriale e le telecomunicazioni.