CRACI vs Kusari

La risposta breve

Kusari è una piattaforma di sicurezza della software supply chain creata dal team che ha co-creato GUAC, il grafo open source per i metadati della supply chain. Costruisce un knowledge graph aggiornato di continuo a partire da sorgenti, SBOM, documenti VEX e output degli scanner esistenti, classifica ciò che è sfruttabile, esamina le pull request e apre correzioni. CRACI è un runner GitHub Actions. Registra ciò che ogni build scarica durante l'esecuzione, controlla che cosa la build può raggiungere e continua a monitorare ciò che è stato distribuito. Ogni grafo riflette le SBOM che riceve; CRACI produce le SBOM dalla build stessa. I due competono per lo stesso budget di supply chain. Per il software che compila Lei, CRACI copre la CI, la SBOM e il tracciamento delle vulnerabilità in un unico prodotto.

In sintesi

Kusari e GUAC, con precisione

GUAC (Graph for Understanding Artifact Composition) è un progetto OpenSSF in incubazione nell'ambito del working group Supply Chain Integrity, con licenza Apache 2.0. Aggrega i metadati di sicurezza del software in un database a grafo. Tra i suoi input documentati figurano SBOM CycloneDX e SPDX, attestazioni in-toto e SLSA, documenti OpenVEX e CSAF, risultati di OpenSSF Scorecard, dati OSV e deps.dev. GUAC aggrega metadati prodotti da altri strumenti; non esegue build.

I co-fondatori di Kusari hanno co-creato GUAC con Google, e un co-fondatore di Kusari è il lead maintainer di GUAC. Kusari afferma di usare e curare GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined e altri progetti open source nei suoi prodotti commerciali. GUAC ha anche altri contributori, tra cui Google, Red Hat, Purdue University e Citi. Kusari è la piattaforma commerciale; GUAC è il progetto della community.

Che cosa fa bene Kusari

Un grafo costruito su standard aperti. La piattaforma di Kusari acquisisce sorgenti, artefatti di build, SBOM CycloneDX e SPDX, VEX e output degli scanner esistenti, compresi i risultati di Snyk, Black Duck, Prisma Cloud, Dependabot e GitHub Advanced Security. Mappa le dipendenze dirette e transitive con provenance e lineage, e mostra il blast radius di una nuova vulnerabilità sull'intero parco software.

Meno risultati, ma migliori. L'analisi di raggiungibilità e di sfruttabilità cerca prove che il codice vulnerabile venga realmente chiamato, così in coda resta ciò che conta. AutoFix genera pull request di correzione e le convalida prima che raggiungano il Suo repository.

Controlli sulla pull request. Kusari Inspector esamina ogni pull request su GitHub o GitLab alla ricerca di vulnerabilità transitive, secret esposti, pacchetti malevoli e di typosquatting, rischi di licenza, dipendenze a fine vita, workflow GitHub Actions non sicuri e comuni debolezze del codice. Kusari afferma che Inspector si installa gratuitamente, senza bisogno di una chiamata commerciale.

Standard e framework. Kusari produce SBOM e attestazioni nei formati SPDX, CycloneDX e in-toto, e dichiara il supporto a framework tra cui il CRA dell'UE, FDA 524B, SSDF, IEC 62443 e DORA. Il suo uploader funziona con GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines e TeamCity.

In che cosa CRACI è diverso

Kusari descrive il proprio grafo come costruito da codice sorgente e sistemi di build mentre il software viene creato, anziché ricostruito da binari finiti. È l'intuizione giusta, ed è anche il punto in cui i due prodotti divergono. Le SBOM di Kusari provengono da un generatore: la sua documentazione descrive la generazione con waybill, il suo toolkit SBOM open source, al merge delle pull request, oppure l'uso di un proprio strumento. Un generatore legge lockfile, manifest, cache e immagini. CRACI non legge i file della build per dedurre che cosa ha usato. È la macchina su cui gira la build.

Una registrazione, non una ricostruzione

Con una modifica di una riga a runs-on, il Suo workflow gira su CRACI. Un proxy che riconosce i pacchetti registra ciò che ogni job scarica dalle sorgenti dei pacchetti, e i pacchetti ripristinati dalle cache CI vengono riportati nella registrazione. Ogni SBOM indica quanto è completa, per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Il monitoraggio parte da ciò che la build ha effettivamente scaricato e sa dove sono le lacune.

Controllo durante la build

Un grafo aiuta a trovare a posteriori ciò che è colpito. Una policy di egress sul runner decide, durante l'esecuzione del job, quali host può raggiungere. Le policy di CRACI sono a negazione o autorizzazione predefinita, con 24 preset integrati di sorgenti software, vengono validate prima dell'avvio del job e operano in modalità fail closed.

Provenance e monitoraggio dalla stessa registrazione

L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance. Continua a rivalutare le SBOM monitorate.

CRACI non fa ciò che rende distintivo Kusari: non importa i risultati di altri scanner, non analizza la raggiungibilità e non esamina le pull request alla ricerca di pacchetti malevoli e debolezze del codice. Oggi supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap.

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 arriva una nuova vulnerabilità, Lei può vedere quali prodotti eseguono la versione interessata, invece di ricostruirlo da note di rilascio e fogli di calcolo.

Sostituire Kusari con CRACI

Per il software che compila e distribuisce, CRACI copre ciò per cui di solito si acquista una piattaforma a grafo. Esegue la build, registra la SBOM con una completezza dichiarata, 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 di assegnare ciascuno al team responsabile della correzione. La policy di egress limita fin dall'inizio ciò che una build può raggiungere, cosa che nessun grafo può fare.

Sia consapevole di ciò a cui rinuncia. Kusari collega un unico grafo tra molti scanner e fonti di SBOM, acquisisce VEX, analizza la raggiungibilità ed esamina le pull request alla ricerca di pacchetti malevoli, secret esposti e debolezze del codice. CRACI oggi non fa nulla di tutto ciò, e oggi supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. Se correlare i risultati di molti strumenti esistenti è la Sua esigenza principale, Kusari resta la scelta più adatta.

Per il CRA

Il Cyber Resilience Act chiede ai fabbricanti di documentare i componenti dei loro prodotti, anche con una SBOM, e di gestire le vulnerabilità per tutto il tempo in cui un prodotto è supportato. La segnalazione delle vulnerabilità attivamente sfruttate si applica da settembre 2026. Kusari collega SBOM, VEX e risultati in un unico grafo, e indica il CRA tra i framework che supporta. CRACI produce le evidenze per build e continua a monitorarle: con che cosa è stata compilata ogni release, con provenance, monitoraggio continuo ed esportazione delle SBOM in CycloneDX o SPDX. 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; nessuno dei due strumenti rende conforme un prodotto da solo. Legga che cosa richiede il CRA.

Passare a CRACI

Imposti runs-on: craci sui workflow che compilano ciò che distribuisce. CRACI sostituisce il runner, non GitHub Actions, e le esecuzioni continuano a comparire nell'interfaccia di GitHub. Scopra di più sulla generazione di SBOM in fase di build e sul tracciamento delle vulnerabilità.

Sta valutando più di due strumenti? Alternative a Kusari confronta nove opzioni fianco a fianco.