Confronto
I migliori strumenti SBOM del 2026
Il miglior strumento SBOM dipende dal compito. Syft, Trivy e cdxgen generano SBOM scansionando file; Dependency-Track, FOSSA e Anchore le gestiscono; CRACI registra la SBOM mentre la Sua build è in esecuzione. Ecco in che cosa differiscono dodici strumenti e come scegliere.
Aggiornato il
La risposta breve
- SBOM gratuite per immagini container e filesystem: Syft, oppure Trivy se Le serve anche uno scanner di vulnerabilità, secret e IaC.
- CycloneDX dal codice sorgente: cdxgen, dalla community CycloneDX.
- SPDX per un output di build che già impacchetta: Microsoft SBOM Tool.
- Workload su AWS: Amazon Inspector SBOM Generator, che alimenta Amazon Inspector.
- Una SBOM rapida di un repository GitHub: l'esportazione del dependency graph di GitHub.
- Un luogo gratuito e self-hosted per monitorare le SBOM: OWASP Dependency-Track.
- Prima di tutto la conformità delle licenze: FOSSA. SBOM di fornitori e portafoglio: Manifest o Cybeats. Flotte di container e policy pack governativi: Anchore Enterprise.
- Una SBOM di ciò che le Sue build hanno effettivamente scaricato, con monitoraggio delle vulnerabilità e dati di provenance: CRACI, per GitHub Actions.
Che cosa fa uno strumento SBOM
Una software bill of materials elenca i componenti, le librerie e le dipendenze contenuti in un software, in un formato leggibile da macchina come CycloneDX o SPDX. Gli strumenti SBOM sono di due tipi. I generatori scrivono la SBOM. I manager archiviano le SBOM di molti prodotti e fornitori, le confrontano con i dati sulle vulnerabilità, applicano policy e le condividono. I manager dipendono da ciò che ricevono dai generatori.
Il momento in cui viene acquisita la SBOM conta quanto lo strumento che la acquisisce. La guida di CISA sui tipi di SBOM distingue una SBOM source, creata dall'ambiente di sviluppo e dai file sorgente, una SBOM build, generata come parte della build dell'artefatto rilasciabile, e una SBOM analyzed, generata analizzando artefatti come eseguibili e immagini container dopo la build. La maggior parte dei generatori qui sotto produce SBOM source o analyzed. CRACI produce una SBOM build. La pagina sulle SBOM in fase di build spiega la differenza nel dettaglio.
A chi è rivolta questa pagina
Questa pagina è per i team che hanno bisogno di SBOM, per il Cyber Resilience Act, per il questionario di un cliente o per il proprio lavoro sulle vulnerabilità, e stanno valutando le opzioni. Noi sviluppiamo CRACI, ne tenga conto. Ogni affermazione su un altro strumento proviene dalla sua documentazione, e ogni strumento ha una pagina CRACI vs X più lunga.
Come scegliere uno strumento SBOM
- Deve produrre SBOM, gestirle o entrambe le cose? Un generatore Le dà un file. Un manager Le dà un luogo in cui conservare i file di molti prodotti e fornitori, arricchirli e agire di conseguenza.
- Il software è Suo o acquistato? Per le Sue build controlla l'input, quindi può registrarlo. Per il software dei fornitori servono acquisizione, validazione e talvolta analisi dei binari.
- Quanto deve essere sicuro che l'elenco sia completo? I generatori leggono i file a posteriori, e divergono più di quanto la maggior parte delle persone si aspetti (veda sotto). Una SBOM build descrive ciò che la build ha usato.
- Quale formato chiedono i Suoi clienti? CycloneDX e SPDX sono entrambi ampiamente accettati; la maggior parte degli strumenti ne scrive almeno uno.
- Quale CI usa, e deve essere self-hosted? I generatori open source funzionano ovunque. Oggi CRACI supporta GitHub Actions su Linux, come servizio gestito, con GitLab CI, Jenkins e i runner ospitati dal cliente in roadmap.
Generatori di SBOM
Qui si confronta ciò che fa ogni generatore, non quanti componenti restituisce.
| Funzionalità | CRACI | Syft | Trivy | cdxgen | Microsoft SBOM Tool | Export di GitHub | Amazon Inspector Sbomgen |
|---|---|---|---|---|---|---|---|
| Da dove proviene l'elenco dei componenti | Traffico della build registrato | I cataloger leggono file e immagini | Lockfile o pacchetti installati | Sorgenti e immagini container | Una cartella di output della build | Manifest e lockfile | File in immagini, directory, archivi e binari |
| Formati | CycloneDX, SPDX | CycloneDX, SPDX, Syft JSON | CycloneDX, SPDX | CycloneDX | SPDX | SPDX | CycloneDX |
| Registra ciò che la build ha scaricato | Cache CI incluse | Dependency submission | |||||
| Funziona senza eseguire la build | |||||||
| Attestazione o provenance firmata | Nessuna provenance firmata | Attestazione SBOM in-toto | Con Cosign | Non dichiarato | Non dichiarato | Artifact attestation | Non dichiarato |
| Confronto con le vulnerabilità | SBOM monitorate | Da abbinare a Grype | Non dichiarato | Non dichiarato | Avvisi Dependabot | Inspector Scan API | |
| Policy di egress per la build | Fail-closed | ||||||
| Funziona in qualsiasi CI | Oggi GitHub Actions; GitLab CI e Jenkins nella roadmap | Repository GitHub | Solo Linux | ||||
| Prezzo | Pagamento per minuto di build, senza canone mensile | Gratuito, Apache-2.0 | Gratuito, Apache-2.0 | Gratuito, Apache-2.0 | Gratuito, MIT | Incluso con GitHub | Download gratuito |
- Incluso
- In parte
- Non incluso
- In roadmap
CRACI
CRACI è un registratore, non uno scanner. I Suoi job GitHub Actions vengono eseguiti sui runner CRACI, e un proxy che riconosce i pacchetti registra ciò che ogni job scarica, compresi i pacchetti ripristinati da una cache CI. La SBOM, in CycloneDX o SPDX, include le dipendenze transitive usate dalla build e ne dichiara la completezza per job e per cache. CRACI poi continua a rivalutare le SBOM monitorate, quindi svolge insieme il lavoro di un generatore e di un manager. Ideale per il software che Lei compila in GitHub Actions. Attenzione: non può scansionare un'immagine o una directory, e oggi esegue job Linux su GitHub Actions (altri sistemi CI, Windows e macOS sono in roadmap). Generazione di SBOM in CRACI
Syft
Syft è il generatore gratuito di Anchore, con licenza Apache-2.0, per immagini container e filesystem. Riconosce decine di tipi di pacchetti, scrive CycloneDX, SPDX e Syft JSON e può creare attestazioni SBOM in-toto firmate. Grype, il suo complemento, confronta la SBOM con le vulnerabilità. Ideale per le immagini e per qualsiasi pipeline che abbia bisogno di un generatore gratuito. Attenzione: i cataloger vengono scelti in base al tipo di scansione, quindi su un checkout di express con le dipendenze installate un solo flag decide se i pacchetti npm compaiono o meno nel risultato. CRACI vs Syft e Grype
Trivy
Trivy, di Aqua Security, è uno scanner versatile con licenza Apache-2.0 per immagini, filesystem, repository, immagini VM e Kubernetes. Trova vulnerabilità, configurazioni IaC errate, secret e licenze, e come effetto collaterale scrive CycloneDX o SPDX. Ideale per i team che vogliono un unico binario gratuito per molti controlli di sicurezza. Attenzione: per un repository legge i lockfile, quindi express 5.2.1 (senza lockfile) e claude-code (senza manifest) non gli danno nulla da leggere, esattamente come documentato. CRACI vs Trivy
cdxgen
cdxgen è un progetto OWASP CycloneDX che crea BOM CycloneDX da sorgenti e immagini container, con licenza Apache-2.0. Ideale per i team che hanno adottato CycloneDX come standard e vogliono un generatore della community del formato. Attenzione: come gli altri scanner, può riportare solo ciò che dichiarano i file che ha davanti. CRACI vs uno stack SBOM fai da te
Microsoft SBOM Tool
Microsoft SBOM Tool è un generatore con licenza MIT che scrive SPDX 2.2, o SPDX 3.0 su richiesta, e può validare una SBOM rispetto alla specifica SPDX. Si aspetta sulla riga di comando una cartella di output della build, un nome di pacchetto, una versione e un fornitore, il che lo rende un passaggio post-build, e funziona in GitHub Actions e Azure Pipelines. Ideale per i team che vogliono SPDX per un output di build che già impacchettano. Attenzione: puntato su repository così come sono nel commit, invece che su un output di build, non ha quasi nulla da descrivere. Poiché riceve un fornitore sulla riga di comando, può compilare il campo supplier. CRACI vs uno stack SBOM fai da te
Esportazione del dependency graph di GitHub
Il dependency graph di GitHub riassume i manifest e i lockfile di un repository, più tutto ciò che viene inviato tramite la dependency submission API, e si esporta come SPDX dalla UI o dalla REST API. Alimenta gli avvisi di Dependabot ed è incluso in tutti i piani GitHub. Ideale per i team già su GitHub che hanno bisogno di una SBOM rapida. Attenzione: riflette il branch predefinito e non un commit fissato, e si basa su ciò che GitHub sa del repository, non sui file letti da uno scanner. CRACI vs GitHub Advanced Security
Amazon Inspector SBOM Generator
Sbomgen è il generatore alla base della scansione di immagini, Lambda ed EC2 di Amazon Inspector, offerto come binario Linux autonomo. Legge i metadati dei pacchetti da immagini container, directory, archivi, volumi montati e binari compilati Go e Rust, copre i pacchetti del sistema operativo (APK, DPKG, RPM) e linguaggi tra cui C#, Go, Java, Node.js, PHP, Python, Ruby e Rust, e scrive CycloneDX. Può inviare la SBOM alla Amazon Inspector Scan API per ottenere risultati sulle vulnerabilità, il che richiede un account AWS. Ideale per i team i cui workload girano già su AWS. Attenzione: funziona solo su Linux e, come gli altri scanner, trova ciò che dichiarano i file che legge.
Safeguard
La CLI di Safeguard esegue Syft e Grype per produrre SBOM CycloneDX e SPDX da repository, immagini container e manifest caricati, e la sua piattaforma aggiunge pull request di correzione scritte dall'IA e policy gate. Ideale per i team che vogliono scansione e correzioni automatizzate in un unico abbonamento. Attenzione: come gli altri scanner, elenca ciò che dichiarano i file che legge. CRACI vs Safeguard
Da che cosa dipende una SBOM da scansione
Punti i generatori qui sopra sullo stesso repository e restituiranno elenchi diversi. Questi sono gli schemi previsti dalla documentazione stessa degli strumenti:
- Gli strumenti non concordano su che cosa sia un componente. Ogni generatore decide da sé di quali file fidarsi e come denominare ciò che trova, quindi un repository dà a ciascuno un elenco diverso.
- Niente lockfile, niente dipendenze. Express 5.2.1 non ne include nessuno, quindi un generatore che risolve le dipendenze dai lockfile non riporta nessuna delle sue dipendenze npm e restituisce qualunque altra cosa riconosca.
- Nessun manifest. Il repository claude-code non ha né manifest né lockfile, quindi ciò che ogni strumento restituisce è ricavato da altri tipi di file e dice più sullo strumento che sul progetto.
- Metadati scarsi. Il campo supplier risulta spesso vuoto, perché la maggior parte dei generatori non ha alcuna fonte per compilarlo.
Nessuno di questi strumenti è difettoso. Ciascuno legge i file che ha davanti, come previsto. La lezione è che una SBOM da scansione dipende dallo strumento, dalle sue impostazioni e dal fatto che qualcuno abbia installato prima le dipendenze. Per sapere che cosa leggono Syft, Trivy e cdxgen, veda che cosa non vedono i generatori di SBOM open source.
Manager di SBOM
| Funzionalità | CRACI | Anchore Enterprise | FOSSA | Cybeats | Manifest | Dependency-Track |
|---|---|---|---|---|---|---|
| Da dove proviene la SBOM | Registrata durante la Sua build | Scansioni di immagini, filesystem e sorgenti | Analisi con FOSSA CLI, o importazioni | Importazioni; generatori tramite il suo Marketplace | Scanner (Syft per impostazione predefinita) o analisi dei binari | SBOM caricate da Lei |
| Indicazione di completezza o qualità | Per job e per cache | Validazione dello schema | Policy sugli elementi minimi | SBOM Quality Score | Non dichiarato | Non dichiarato |
| Importa le SBOM dei fornitori | Si possono aggiungere le SBOM dei fornitori | Portale fornitori | CycloneDX | |||
| Monitoraggio continuo delle vulnerabilità | ||||||
| VEX | ||||||
| Motore di policy o gate | Policy gate, blocco delle build | Policy pack | Avvisi basati su policy | Non dichiarato | ||
| Conformità delle licenze | La policy sulle licenze può bloccare una build | Non dichiarato | Non dichiarato | |||
| Condivisione delle SBOM con i clienti | Esportazione di file | Non dichiarato | SBOM Portal | Non dichiarato | ||
| Esegue la Sua build | Policy di egress, provenance | |||||
| Self-hosted | Runner ospitati dal cliente | Anche air-gapped | Non dichiarato | Non dichiarato | Non dichiarato | |
| Prezzi | $0.002 per vCPU-minuto ($0.004 per 2 vCPU), misurati al secondo; nessun canone mensile | Su preventivo | Piano gratuito; Business $20 per progetto al mese | Non dichiarato | Non dichiarato | Gratuito, Apache 2.0 |
- Incluso
- In parte
- Non incluso
- In roadmap
Anchore Enterprise
Anchore Enterprise si basa su Syft e Grype e aggiunge ciò che serve alle grandi organizzazioni: SBOM di container, sorgenti e filesystem, SBOM importate con validazione della correttezza dello schema, nuova scansione continua senza l'artefatto originale e policy pack per FedRAMP, NIST, CIS, PCI DSS e CMMC. Si distribuisce su Kubernetes, Docker Compose o in ambienti air-gapped. Ideale per flotte di container su più sistemi CI e per il lavoro governativo. Attenzione: le sue SBOM descrivono comunque ciò che ha trovato uno scanner, e il prezzo è su preventivo. CRACI vs Anchore
FOSSA
FOSSA è nato con la conformità delle licenze: rilevamento delle licenze a testo integrale, policy e note di attribuzione. Genera e importa SBOM SPDX e CycloneDX, può aggiungere dichiarazioni VDR o VEX, verifica le importazioni rispetto agli elementi minimi di NTIA e FDA e condivide le SBOM tramite un portale nel piano Enterprise. Il piano Free copre 5 progetti. Ideale per i team la cui prima preoccupazione è il rischio di licenza. Attenzione: la sua CLI interroga i Suoi strumenti di build quando è disponibile una build funzionante e in caso contrario deduce dai sorgenti, mentre la scansione di binari e snippet è un componente aggiuntivo. CRACI vs FOSSA
Cybeats SBOM Studio
SBOM Studio si definisce "the SBOM system of record." Importa ed esporta SPDX da 2.2 a 3.0.1 e CycloneDX da 1.2 a 1.7, valuta la qualità delle SBOM prima dell'importazione, confronta ogni componente di continuo e condivide dati SBOM e VEX con i clienti, anche tramite la Transparency Exchange API. Ideale per i team di product security in ambito ICS, dispositivi medici, telecomunicazioni e automotive che gestiscono un programma SBOM. Attenzione: gestisce le SBOM invece di produrle, e un punteggio di qualità conferma il formato, non ciò che il generatore non ha visto. CRACI vs Cybeats e Alternative a Cybeats
Manifest
Manifest raccoglie, arricchisce e condivide le SBOM dei Suoi prodotti, dei Suoi fornitori e dei Suoi modelli di IA. I fornitori caricano le SBOM tramite un portale sicuro e, quando non ne forniscono, Manifest può analizzare il binario e generarne una. Supporta SPDX, CycloneDX e VEX e si allinea alle linee guida FDA, a NIST 800-218 e a UNECE R155. Ideale per le organizzazioni la cui principale esposizione è il software che acquistano. Attenzione: la sua GitHub Action genera le SBOM first-party con Syft per impostazione predefinita. CRACI vs Manifest
OWASP Dependency-Track
Dependency-Track è una piattaforma con licenza Apache 2.0 che traccia i componenti in ogni versione di ogni applicazione, acquisisce dati sulle vulnerabilità da fonti come NVD e GitHub Advisories, applica policy di sicurezza, di licenza e operative, e consuma e produce CycloneDX VEX. Le pipeline caricano le SBOM tramite la sua API. Ideale per i team che vogliono una piattaforma di analisi trasparente e self-hosted. Attenzione: non genera SBOM, e deve gestirla Lei (il server API richiede almeno 2 GB di RAM e 2 core CPU). CRACI per gli utenti di Dependency-Track
CycloneDX o SPDX
Entrambi i formati sono standard aperti, e la maggior parte degli strumenti in questa pagina ne scrive almeno uno. CycloneDX è un progetto OWASP, standardizzato da Ecma International come ECMA-424, e contiene dati su vulnerabilità e VEX accanto all'elenco dei componenti. SPDX è un progetto della Linux Foundation e uno standard internazionale, ISO/IEC 5962:2021. Il Cyber Resilience Act chiede "un formato di uso comune e leggibile da dispositivo automatico" senza indicarne uno, quindi scelga il formato che i Suoi clienti e i Suoi strumenti a valle leggono. Veda gli esempi di SBOM per i due formati fianco a fianco, e le best practice per le SBOM per come gestirle. Per archiviare e monitorare le SBOM su larga scala, veda la gestione delle SBOM.
Dove si colloca CRACI
CRACI non è né uno scanner né un manager. È un registratore. I Suoi job GitHub Actions vengono eseguiti sui runner CRACI (cambi
runs-on in craci), e 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. I pacchetti ripristinati da una cache CI portano con sé le
loro evidenze. La SBOM, in CycloneDX o SPDX, include le dipendenze transitive usate dalla build e ne dichiara la
completezza per job e per cache: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale.
Dopo la build, CRACI continua a rivalutare le SBOM monitorate, aggrega le vulnerabilità di tutte le build e di tutti i repository, supporta VEX, restituisce SBOM, tracce di rete e provenance tramite la sua API ed esporta le SBOM come file CycloneDX o SPDX. Si possono aggiungere le SBOM dei fornitori, così i componenti acquistati vengono monitorati insieme alle Sue build. 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. Veda la generazione di SBOM in CRACI per la funzionalità completa.
Quindi CRACI svolge insieme il lavoro di un generatore e di un manager, per il software che Lei compila. Non è la scelta giusta quando:
- ha bisogno di SBOM per immagini o software che non ha compilato (usi un generatore come Syft o Trivy),
- ha bisogno di un motore di policy maturo con molti tipi di regole su un portafoglio di prodotti e fornitori (usi un manager),
- le Sue pipeline girano fuori da GitHub Actions, su Windows o macOS, o devono essere self-hosted (tutte voci della roadmap di CRACI).
Il modo più rapido per giudicare è il confronto diretto: prenoti una demo, esegua uno dei Suoi workflow su CRACI e metta la sua SBOM accanto a quella prodotta dal Suo strumento attuale.
Veda anche gli strumenti SCA a confronto, SBOM generate dall'IA e SBOM in fase di build e perché le SBOM in fase di build differiscono da quelle da scansione.
Strumenti SBOM: domande frequenti
Che cos'è uno strumento SBOM?
Uno strumento SBOM produce o gestisce una software bill of materials: un elenco leggibile da macchina dei componenti, delle librerie e delle dipendenze contenuti in un software. I generatori come Syft, Trivy e cdxgen scrivono la SBOM leggendo i file. I manager come Dependency-Track, FOSSA e Anchore Enterprise archiviano le SBOM, le confrontano con i dati sulle vulnerabilità e le condividono. CRACI registra la SBOM durante la build stessa e poi la monitora.
Qual è il miglior strumento SBOM gratuito?
Dipende da ciò a cui lo punta. Syft e Trivy sono generatori gratuiti con licenza Apache-2.0 per immagini container e filesystem. cdxgen scrive CycloneDX da sorgenti e immagini. Microsoft SBOM Tool scrive SPDX per una cartella di output della build. OWASP Dependency-Track è un manager gratuito e self-hosted per le SBOM prodotte da quegli strumenti.
Meglio usare Syft o Trivy?
Syft è focalizzato sulla generazione di SBOM e si abbina a Grype per il confronto con le vulnerabilità. Trivy è uno scanner più ampio che trova anche configurazioni IaC errate, secret e licenze, e nel farlo scrive CycloneDX o SPDX. Entrambi leggono i file che hanno davanti, quindi entrambi dipendono dalla presenza di lockfile o pacchetti installati.
CycloneDX o SPDX: quale formato SBOM usare?
Entrambi sono standard aperti e ampiamente supportati. CycloneDX è un progetto OWASP, standardizzato da Ecma International come ECMA-424, e contiene anche dati su vulnerabilità e VEX. SPDX è un progetto della Linux Foundation e uno standard internazionale, ISO/IEC 5962:2021. Usi quello richiesto dai Suoi clienti e dai Suoi strumenti a valle; la maggior parte dei generatori li scrive entrambi.
Perché gli strumenti SBOM danno risultati diversi per lo stesso progetto?
Ogni generatore decide di quali file fidarsi e che cosa conta come componente. Alcuni leggono i lockfile, altri i pacchetti installati, altri i binari, e un repository senza lockfile non offre nulla su cui lavorare a chi legge i lockfile. Una SBOM da scansione dipende dallo strumento, dalle sue impostazioni e dal fatto che le dipendenze siano state installate prima della scansione. Una SBOM in fase di build evita il problema registrando ciò che la build ha effettivamente scaricato.
Il Cyber Resilience Act richiede uno strumento o un formato SBOM specifico?
No. L'allegato I, parte II del CRA chiede ai fabbricanti di redigere una distinta base del software in un formato di uso comune e leggibile da dispositivo automatico che comprenda almeno le dipendenze di primo livello dei prodotti. CycloneDX e SPDX sono entrambi idonei. Il regolamento non indica alcuno strumento.
CRACI può generare una SBOM per software che non ho compilato io?
No. CRACI registra le build eseguite sui suoi runner, quindi le sue SBOM descrivono il software che Lei compila. Per il software che acquista, può aggiungere a CRACI la SBOM del fornitore e monitorarla insieme alle Sue build. Per un'immagine container di terze parti che non ha compilato, uno scanner come Syft o Trivy è la scelta pratica.
Quali sistemi CI supporta CRACI?
Oggi GitHub Actions, su runner Linux x86-64 e ARM64. Lei cambia runs-on in craci e le esecuzioni continuano a comparire in GitHub. Altri sistemi CI, a partire da GitLab CI e Jenkins, sono in roadmap.
Metta una SBOM registrata accanto a quella attuale
Prenoti una demo, esegua un workflow GitHub Actions su CRACI e confronti la sua SBOM con quella prodotta oggi dal Suo generatore.
Prenota una demo