CRACI vs uno stack SBOM fai da te

La risposta breve

Uno stack fai da te composto da Syft o Trivy, Grype, Dependency-Track, Cosign e Renovate ha licenze gratuite, gira ovunque e offre a un team di piattaforma capace il pieno controllo. CRACI è un runner GitHub Actions gestito che registra ciò che ogni build ha scaricato, controlla dove può connettersi, monitora ciò che è stato distribuito ed esporta le evidenze. La differenza riguarda meno le funzionalità e più la provenienza della SBOM e chi si occupa dei punti di giunzione. Se Lei compila su GitLab, Jenkins o Windows, oppure se tutto deve girare sulla Sua infrastruttura, oggi la raccomandazione onesta è il fai da te.

Com'è fatto lo stack

Una soluzione completa costruita in proprio ha di solito sette livelli. Ognuno è un vero progetto con una propria manutenzione.

Generazione. Syft ("generating a Software Bill of Materials (SBOM) from container images and filesystems"), Trivy, cdxgen (un progetto OWASP che crea BOM CycloneDX "from source and container images") oppure Microsoft SBOM Tool, che scrive SPDX e si aspetta da riga di comando una cartella di drop della build, un nome di pacchetto, una versione e un fornitore.
Confronto. Grype scansiona immagini, filesystem e SBOM, con EPSS, KEV e punteggio di rischio. OSV-Scanner confronta lockfile, SBOM e immagini container con OSV.dev.
Gestione. OWASP Dependency-Track acquisisce SBOM CycloneDX e le monitora nel tempo. Il suo API server richiede almeno 2 GB di RAM e 2 core CPU (consigliati 8 GB e 4 core), e la sua documentazione indirizza i deployment di produzione verso Docker Compose con un database separato.
Firma. Cosign firma immagini, blob e attestazioni SBOM, con firma keyless tramite Fulcio e un transparency log Rekor. Le GitHub artifact attestations si basano su Sigstore e forniscono provenance SLSA v1.0 Build Level 2.
Aggiornamenti. Renovate o Dependabot aprono pull request per mantenere aggiornate le dipendenze.
Controllo dell'egress. StepSecurity Harden-Runner può controllare o bloccare le connessioni in uscita dai job GitHub Actions. Il suo livello Community è gratuito per i repository pubblici sui runner ospitati da GitHub; i repository privati e i runner self-hosted richiedono il livello Enterprise. L'alternativa sono un proxy e regole firewall propri attorno ai runner self-hosted.
Reporting. Qualcuno trasforma l'output di tutto ciò nei documenti che servono a un auditor, a un cliente o a un fascicolo tecnico CRA.

Funzionalità	CRACI	Stack fai da te
Esegue le Sue build	I job vengono eseguiti sui runner CRACI	Gli strumenti girano come step nella Sua CI
SBOM registrata dalla build	Download osservati, compresi i pacchetti in cache	Ricostruita dai file a posteriori
Completezza della SBOM	Dichiarata per job e per cache	Dipende dal generatore, dalle sue impostazioni e dall'aver prima eseguito l'installazione
Policy di egress sul runner	Negazione o autorizzazione predefinita, fail closed	Harden-Runner o un proxy proprio
Provenance firmata	Nessuna provenance firmata	Cosign o GitHub artifact attestations
Monitoraggio delle SBOM distribuite	Le SBOM monitorate vengono rivalutate di continuo	Dependency-Track, una volta ospitato da Lei
Policy di portafoglio, VEX e triage	Triage, VEX e policy sulle licenze	Policy e VEX di Dependency-Track
Evidenze e report per il CRA	SBOM in CycloneDX o SPDX, registrazioni tramite API; nessuna esportazione di report	I report li assembla Lei da ogni strumento
Altri sistemi CI, Windows e macOS	Oggi Linux su GitHub Actions; altri sistemi CI, Windows e macOS in roadmap	Generatori e scanner girano in qualsiasi CI
Gira sulla Sua infrastruttura	Oggi gestito; runner ospitati dal cliente in roadmap, Enterprise	Strumenti open source ospitati da Lei
Costo	$0.002 per vCPU-minuto ($0.004 per 2 vCPU), misurati al secondo; nessun canone mensile e nessun costo per SBOM	Licenze gratuite. Si paga in tempo di engineering, hosting e manutenzione.

Incluso
In parte
Non incluso
In roadmap

Il costo sta nei punti di giunzione

Scegliere un generatore significa sceglierne i punti ciechi

Punti più generatori di SBOM sullo stesso repository e non saranno d'accordo su che cosa contiene. Ciascuno legge un insieme diverso di file e li risolve in modo diverso, quindi l'elenco dei componenti che ottiene dipende dallo strumento scelto quanto dal progetto. Il campo fornitore dell'NTIA mostra la stessa cosa dall'altro lato: la maggior parte dei generatori non ha una fonte per questo dato, quindi risulta vuoto qualunque cosa contenga il repository.

Nessuno di questi strumenti è difettoso. Ciascuno prende una decisione diversa e documentata su che cosa conta come componente e di quali file fidarsi. Ma uno stack fai da te eredita le decisioni degli strumenti che Lei ha scelto, e il resto della pipeline (confronto, monitoraggio, reporting) può essere completo solo quanto quel primo passaggio.

Il collante è a Suo carico

Ogni strumento ha la propria cadenza di release, il proprio database di vulnerabilità, il proprio formato di output e la propria configurazione. Qualcuno deve fissare le versioni, aggiornare i database, mantenere patchati Dependency-Track e il suo database, ruotare le identità di firma, decidere quale SBOM va dove e accorgersi quando uno step inizia in silenzio a produrre meno. È lavoro di piattaforma continuativo, non una configurazione una tantum.

Anche gli strumenti sono dipendenze

Gli strumenti di sicurezza girano all'interno delle Sue build con accesso ai Suoi secret, quindi rientrano nel Suo threat model. Nel marzo 2026, Aqua Security ha pubblicato un advisory che descrive come credenziali compromesse siano state usate per pubblicare una release malevola di Trivy e per fare un force push della maggior parte dei tag di trivy-action verso codice che ruba credenziali, per circa 12 ore. Aqua lo ha documentato pubblicamente, e sarebbe potuto accadere a qualsiasi progetto molto diffuso. Dimostra perché il controllo dell'egress sul runner è importante: una policy di negazione predefinita limita le destinazioni verso cui uno step compromesso può inviare dati, ma non tutti i canali (l'advisory descrive anche un ripiego che creava repository nell'account GitHub della vittima).

Quando il fai da te è la scelta giusta

La Sua CI non è GitHub Actions. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap. I team su GitLab, Jenkins e CircleCI possono eseguire tutti gli strumenti open source elencati sopra.
Compila su Windows o macOS. Oggi i runner CRACI sono Linux (x86-64 e ARM64); Windows e macOS sono in roadmap.
Tutto deve girare sulla Sua infrastruttura. Oggi CRACI opera con runner gestiti su infrastruttura europea, con runner ospitati dal cliente in roadmap per Enterprise.
Ha un team di piattaforma che vuole esserne responsabile. Se mantenere lo stack è un investimento deliberato e Lei gestisce già bene Dependency-Track, lo tenga.
Le serve una SBOM per un solo questionario. Per una richiesta occasionale e di poco conto, può bastare un generatore eseguito a mano.

Che cosa sostituisce CRACI e che cosa no

CRACI copre diversi livelli in un unico posto, a partire dalla build. Lei cambia runs-on in craci e le esecuzioni continuano a comparire nell'interfaccia di GitHub. Un proxy che riconosce i pacchetti registra ciò che ogni job scarica da npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download, e le evidenze sulle dipendenze viaggiano con le cache CI. Ogni job e ogni cache riceve uno stato di completezza: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.

Generazione: CycloneDX e SPDX dalla build registrata, comprese le dipendenze transitive.
Monitoraggio: risultati aggregati tra build e repository, con le SBOM monitorate rivalutate di continuo.
Provenance: l'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance.
Egress: policy per job con 24 preset integrati di sorgenti software, validata prima dell'avvio del job, in modalità fail closed, con avvisi in caso di violazione.
Esportazione: SBOM in CycloneDX o SPDX, comprese le vulnerabilità; nessuna esportazione di report.

Non sostituisce tutto. Le blocklist di pacchetti sono in roadmap. Se Le serve la provenance firmata, tenga Cosign o le GitHub artifact attestations. Renovate o Dependabot restano utili per mantenere aggiornata ogni dipendenza, non solo quelle vulnerabili. Se Dependency-Track è lo strumento in cui lavora il Suo team di sicurezza, la SBOM CycloneDX si scarica tramite la REST API di CRACI e può alimentarlo.

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.

Per il Cyber Resilience Act

Il CRA chiede ai fabbricanti di "individuare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche redigendo una distinta base del software" (allegato I, parte II). La segnalazione delle vulnerabilità attivamente sfruttate si applica da settembre 2026, con 24 ore per la prima notifica. Uno stack fai da te può supportare tutto questo, purché qualcuno sia responsabile della traccia di evidenze che lega ogni release alla sua SBOM. 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, e invia le notifiche previste dal CRA per Suo conto. Qualunque strada scelga, decidere che cosa è attivamente sfruttato resta compito del Suo team. Veda la conformità al CRA e la generazione di SBOM in fase di build.