Checklist di qualità SBOM: come validare le SBOM inviate dai Suoi fornitori

I tre livelli della qualità di una SBOM

Livello	Domanda	Che cosa lo verifica	Che cosa non può dirLe
Valida	Il file si legge e rispetta lo schema del formato e della versione che dichiara?	I validatori di schema	Se un campo contiene qualcosa di utile
Utilizzabile	Ci sono i campi che Le servono, e uno strumento può usarli: identificatori che corrispondono agli advisory, licenze, hash, relazioni?	Controlli sui campi, profili di conformità e punteggi di qualità	Che cosa manca nel file
Completa	Elenca tutto ciò che contiene il software ricevuto?	Il confronto con la build, o con un'analisi del binario consegnato	Niente che legga solo la SBOM può rispondere a questa domanda

La maggior parte dei team che ricevono SBOM si ferma al primo livello. «Il file è valido» è l'inizio del controllo, non il risultato. Il terzo livello è la completezza della SBOM.

I framework in un minuto

Citi il framework in ogni richiesta e in ogni riscontro, così l'asticella è uno standard pubblicato e non la Sua opinione.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 luglio 2021). Sette campi di dati (nome del fornitore, nome del componente, versione, altri identificatori univoci, relazione di dipendenza, autore dei dati della SBOM, timestamp), supporto all'automazione in SPDX, CycloneDX o tag SWID, e pratiche: frequenza, profondità, incognite note, distribuzione e consegna, controllo degli accessi, gestione degli errori. Hash, licenze, fase del ciclo di vita e firme sono indicati come raccomandati, oltre il minimo.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 luglio 2026, dopo una bozza del 22 agosto 2025). Sostituisce gli elementi NTIA. Redatto da 18 organizzazioni di 14 paesi, tra cui la CISA, la NSA, l'FBI, il BSI tedesco e il METI e l'NCO giapponesi. Conta 17 campi di dati, dieci dei quali nuovi: firma dell'autore della SBOM, nome del formato dei dati, versione del formato dei dati, contesto di generazione, nome dello strumento, versione dello strumento, versione della SBOM, valore dell'hash del componente, algoritmo dell'hash del componente e licenza del componente. «Supplier name» diventa «Component Producer». Le sue pratiche sono copertura, identificazione esplicita delle informazioni sconosciute, dati elaborabili automaticamente, gestione degli aggiornamenti, frequenza, e distribuzione e consegna. Il documento formula ogni elemento con «should» (dovrebbe) e afferma di non creare nuovi requisiti: sono gli acquirenti a renderlo vincolante inserendolo nei contratti.
• BSI, TR-03183-2 versione 2.1.0 (20 agosto 2025), Germania. La più rigorosa delle tre, scritta con MUST (deve): JSON o XML, CycloneDX 1.6 o successivo oppure SPDX 3.0.1 o successivo, una SBOM per versione del software, risoluzione ricorsiva delle dipendenze con la completezza di ogni elenco di dipendenze dichiarata, un hash SHA-512 di ogni componente distribuibile, il nome file del componente, le licenze di distribuzione come identificatori SPDX, e package URL o CPE «if it exists» (se esiste). Precisa inoltre che una SBOM non deve contenere informazioni sulle vulnerabilità: queste vanno in un documento VEX o in un advisory.
• Allineamento internazionale. A Shared Vision of SBOM for Cybersecurity (3 settembre 2025) è firmato da 18 organizzazioni di 15 paesi. Il lavoro del G7 sulle SBOM riguarda i sistemi di IA («A shared G7 vision on SBOM for AI», 2025, e «SBOM for AI – Minimum Elements», maggio 2026) e non fissa requisiti per le SBOM dei fornitori di sistemi embedded.
• Automotive. Auto-ISAC ha pubblicato un SBOM Informational Report l'11 febbraio 2025.

La checklist

Come leggere le celle: Obbligatorio significa che il documento usa «deve». Elemento minimo significa che è nell'elenco minimo di quel documento (la base NTIA, o gli elementi «should» della CISA). Raccomandato significa che il documento lo indica oltre il minimo. Non menzionato significa che il documento non lo chiede. Come verificare ogni controllo, e il messaggio da inviare, sono nella sezione successiva.

Controlli a livello di SBOM

Controllo	Perché è importante	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Si legge ed è valida rispetto allo schema dichiarato	Un file che i Suoi strumenti non riescono a leggere non è una SBOM	Obbligatorio: SPDX, CycloneDX o tag SWID	Pratica: SPDX o CycloneDX elaborabile automaticamente	Obbligatorio: JSON o XML
2. La versione della specifica raggiunge la Sua soglia	Le versioni vecchie non possono contenere i campi che Le servono	Non menzionato	Elemento minimo: nome e versione del formato dei dati; evitare versioni deprecate	Obbligatorio: CycloneDX 1.6+ o SPDX 3.0.1+
3. Autore della SBOM	Qualcuno risponde del contenuto	Elemento minimo: «Author of SBOM Data»	Elemento minimo: «SBOM Author», l'organizzazione, non lo strumento	Obbligatorio: «Creator of the SBOM», e-mail o URL
4. Timestamp	Indica quale SBOM è quella attuale	Elemento minimo	Elemento minimo	Obbligatorio; UTC raccomandato
5. Nome e versione dello strumento	Indica che cosa la SBOM può coprire in modo affidabile	Non menzionato	Elemento minimo	Non menzionato
6. Contesto di generazione	Una scansione dei sorgenti e un registro della build della stessa release sono diversi	Raccomandato: fase del ciclo di vita («source», «build», «post-build»)	Elemento minimo: «before build», «build» o «after build»	Nessun campo; il contenuto deve corrispondere a ciò che era disponibile durante la build
7. Versione o numero di serie della SBOM	Distingue una correzione dall'originale	Non menzionato	Elemento minimo: «SBOM Version»	Obbligatorio se il formato lo prevede: «SBOM-URI»
8. Firma dell'autore	Dimostra che il file è arrivato dal fornitore senza modifiche	Raccomandato: la firma è incoraggiata	Elemento minimo: «SBOM Author Signature»	Solo informativo: «ideally» (idealmente) firmata
9. Il componente di primo livello corrisponde a ciò che ha ricevuto	La SBOM della release sbagliata è peggio di nessuna SBOM	Elemento minimo: componenti principali	Elemento minimo: il componente di destinazione	Obbligatorio: il componente principale, radice dell'albero

Controlli a livello di componente

Controllo	Perché è importante	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Nome del componente	La prima cosa che usa ogni corrispondenza	Elemento minimo	Elemento minimo	Obbligatorio; il nome file se manca il nome
11. Versione: nessun valore latest, unknown o vuoto	Gli advisory si applicano a intervalli di versioni	Elemento minimo	Elemento minimo; dichiararlo se sconosciuta	Obbligatorio; la data del file se manca la versione
12. Produttore o fornitore	Distingue due componenti con lo stesso nome e indica chi li corregge	Elemento minimo: «Supplier Name»	Elemento minimo: «Component Producer»	Obbligatorio: «Component creator», e-mail o URL
13. Package URL ovunque l'ecosistema ne abbia uno, CPE dove non c'è; entrambi ben formati	Senza un identificatore (package URL, CPE), nulla può essere confrontato con un database di vulnerabilità	Elemento minimo: «Other Unique Identifiers», come CPE, SWID o PURL, se esistono	Elemento minimo: almeno un identificatore, come CPE o PURL; includerli tutti	Obbligatorio se esiste: CPE o purl
14. Valore e algoritmo dell'hash, corrispondenti al file ricevuto	Dimostra che questa SBOM descrive questo binario	Raccomandato	Elemento minimo: hash dell'artefatto eseguibile, con un algoritmo approvato da un'autorità come il NIST	Obbligatorio: SHA-512 del componente distribuibile
15. Licenza come identificatori o espressioni SPDX, senza NOASSERTION generalizzato	Su questa base il Suo specialista di licenze valuta il copyleft e gli altri obblighi	Raccomandato	Elemento minimo; identificatori SPDX quando possibile	Obbligatorio: licenze di distribuzione, preferibilmente identificatori SPDX
16. Relazioni di dipendenza, e se l'elenco è completo	Mostra che cosa ha introdotto un pacchetto vulnerabile e se ci si può fidare delle lacune	Elemento minimo; indicare quando le dipendenze dirette sono elencate per intero	Elemento minimo	Obbligatorio, con la completezza di ogni elenco dichiarata
17. Nome file	Collega la voce a un file sul dispositivo	Non menzionato	Non menzionato	Obbligatorio
18. Proprietà eseguibile, archivio e strutturato	Indica che tipo di file è ogni componente	Non menzionato	Non menzionato	Obbligatorio

Controlli di copertura

Controllo	Perché è importante	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Profondità transitiva, non solo il primo livello	La maggior parte del codice vulnerabile arriva in modo indiretto	Primo livello obbligatorio; transitive raccomandate	Pratica di copertura: includere le dipendenze transitive; nessuna profondità minima	Obbligatorio: risoluzione ricorsiva
20. Incognite note dichiarate	Una SBOM che dichiara le proprie lacune è affidabile per ciò che elenca	Pratica obbligatoria	Pratica: informazioni sconosciute e riservate contrassegnate	Obbligatorio tramite la dichiarazione di completezza
21. Una SBOM per versione software consegnata	Conta la versione che Lei usa	Obbligatorio: una nuova SBOM per ogni build o release	Pratica: frequenza	Obbligatorio
22. Correzioni inviate come nuova SBOM	Un errore corretto in silenzio non è tracciabile	Pratica: gestione degli errori	Pratica: gestione degli aggiornamenti	Obbligatorio: una SBOM aggiornata quando si correggono errori
23. Plausibilità: nessun duplicato, un numero di componenti adeguato al prodotto, pacchetti del sistema operativo presenti per un dispositivo basato su Linux	La verifica di completezza più economica	Non menzionato	Pratica di copertura: istanze multiple elencate separatamente	Le istanze multiple devono essere elencate separatamente

Come verificare ogni controllo, e che cosa dire al fornitore

Controllo	Come verificarlo in automatico	Messaggio per il fornitore
1, 2. Schema e versione della specifica	Un validatore di schema per il formato e la versione dichiarati; poi confrontare specVersion (CycloneDX) o la versione SPDX con la Sua soglia	«Il file non supera la validazione dello schema CycloneDX 1.6 nei percorsi indicati. La preghiamo di rigenerarlo con un generatore e di validarlo prima dell'invio.»
3-7. Autore, timestamp, strumento, contesto, versione	Presenza dei metadati richiesti: in CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber e version; in SPDX le informazioni di creazione	«La SBOM non indica lo strumento che l'ha prodotta né il contesto di generazione. Sono entrambi CISA 2026 Minimum Elements.»
8. Firma	Una firma è presente e si verifica con la chiave pubblicata dal fornitore	«La preghiamo di firmare la SBOM, o di inviare una firma separata, come descrive l'elemento CISA 2026 SBOM Author Signature.»
9. Componente di primo livello	Nome e versione di metadata.component (CycloneDX) o dell'elemento radice descritto (SPDX) corrispondono al codice articolo e alla versione software ricevuti	«Questa SBOM descrive la versione 5.2.0; abbiamo ricevuto la 5.3.0. La preghiamo di inviare la SBOM della 5.3.0.»
10, 11. Nome e versione	Nessun nome vuoto; nessuna versione vuota, latest o unknown, salvo se dichiarata sconosciuta	«14 componenti non hanno versione. La preghiamo di indicare la versione esatta o di contrassegnarla come sconosciuta.»
12. Produttore	Un fornitore, un produttore o un autore su ogni componente	«Alcuni componenti non hanno un produttore, richiesto dall'elemento CISA 2026 Component Producer.»
13. Identificatori	Ogni purl viene analizzato senza errori da una libreria package URL conforme a ECMA-427; ogni CPE ha una sintassi CPE 2.3 valida ed esiste nel dizionario CPE della NVD	«Nessun componente ha un package URL o un CPE, quindi nessuno può essere confrontato con i database di vulnerabilità. La preghiamo di aggiungere un purl per ogni pacchetto proveniente da un gestore di pacchetti.»
14. Hash	Una voce SHA-512 su ogni componente distribuibile; calcolare lo sha512sum del file ricevuto e confrontare	«La SBOM non contiene hash. BSI TR-03183-2 richiede lo SHA-512 di ogni componente distribuibile.»
15. Licenze	ID o espressioni di licenza risolvibili nell'elenco delle licenze SPDX; contare i valori NOASSERTION e vuoti	«Il 92% dei componenti riporta NOASSERTION come licenza. La preghiamo di indicare identificatori di licenza SPDX.»
16. Dipendenze	Un grafo dependencies (CycloneDX) o relazioni di dipendenza (SPDX); una dichiarazione di completezza, come le compositions CycloneDX con un valore aggregate	«La SBOM è un elenco piatto. La preghiamo di includere le relazioni di dipendenza e di indicare se ogni elenco è completo.»
17, 18. Nome file e proprietà del file	Sono presenti le proprietà che BSI TR-03183-2 definisce per ciascun formato	«La preghiamo di aggiungere il nome file e le proprietà eseguibile, archivio e strutturato, come richiede BSI TR-03183-2 v2.1.0.»
19-23. Copertura	Profondità del grafo delle dipendenze, rilevamento dei duplicati, numero di componenti confrontato con prodotti simili, componenti attesi per tipo di prodotto	«La SBOM non elenca né kernel, né bootloader, né pacchetti del sistema di base per un display basato su Linux. La preghiamo di inviare la SBOM dell'immagine completa.»

Le percentuali e i numeri nei messaggi sono esempi. Inserisca i numeri reali e citi ogni volta il framework e la sua versione.

Che cosa sfugge anche a un buon punteggio

Un file può essere valido, ottenere 9 su 10 e mancare comunque metà del prodotto. I punteggi di qualità leggono i campi presenti; non vedono i componenti assenti.

Esempio pratico. Un fornitore invia la SBOM di un display basato su Linux. È CycloneDX 1.6 valido, ogni componente ha versione, package URL, licenza e hash SHA-512, e il grafo delle dipendenze è ben formato. Elenca l'applicazione del display e 40 librerie. Non elenca il kernel Linux, il bootloader né alcun pacchetto del sistema di base. Tutti i controlli sui campi passano. La SBOM è inutile per le CVE del kernel, che un dispositivo Linux deve monitorare, perché il kernel non c'è.

Come un team ricevente può verificare la completezza:

• Confrontare con un'analisi binaria del firmware consegnato. Alcuni OEM la usano come SBOM sostitutiva finché quella del fornitore non è abbastanza buona, e poi come verifica incrociata.
• Verificare i componenti attesi per tipo di prodotto. Un'immagine Linux ha un kernel, una libreria C e un sistema di init; un controllore industriale ha i suoi stack di protocollo.
• Chiedere il contesto di generazione e lo strumento. Una scansione dei sorgenti non vede ciò che la build ha scaricato.
• Chiedere se la SBOM proviene dalla build che ha prodotto il software ricevuto. È la domanda che decide il terzo livello.

Una SBOM piccola può essere legittima. Una ECU bare-metal con firmware proprietario e una calibrazione del produttore può onestamente avere due componenti. Lo accetti quando la SBOM lo dichiara e indica le proprie incognite note, invece di penalizzarla per le dimensioni.

Gli strumenti che automatizzano i controlli

Verificati su GitHub l'11 novembre 2026. Nessuno di questi repository è archiviato.

Strumento	Che cosa verifica	Che cosa non fa	Stato
CycloneDX CLI	Validazione dello schema di CycloneDX da 1.0 a 1.7, JSON o XML; --fail-on-errors per la CI	SPDX, qualità dei campi, profili dei framework	v0.33.1, luglio 2026
sbom-utility	Validazione dello schema di CycloneDX da 1.2 a 1.7 e SPDX da 2.1 a 2.3 in JSON, con varianti di schema personalizzate	SPDX 3, XML, profili dei framework	v0.19.2, giugno 2026
SPDX tools-java	Verify per SPDX da 2.0 a 2.3 e 3.0.1	CycloneDX, profili dei framework	v2.0.7, giugno 2026
SPDX tools-python	pyspdxtools -i: validazione completa di SPDX 2.2 e 2.3	Lettura di SPDX 3, il cui supporto è sperimentale	v0.8.5, marzo 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 e 3.0 rispetto a NTIA 2021, CISA FSCT3 e BSI TR-03183-2 v2.1.0; disponibile anche in versione web	CycloneDX; CISA 2026 è una richiesta aperta	v6.0.0, ottobre 2026
sbomqs	Uno score da 0 a 10 su identificazione, provenienza, integrità, completezza, licenze, vulnerabilità e struttura; profili compliance per CISA 2026, NTIA 2021, BSI TR-03183-2 da v1.1 a v2.1.0, FSCT v3 e OpenChain Telco	Vedere i componenti mancanti	v2.1.3, ottobre 2026; profilo CISA 2026 dalla v2.1.0, corretto nella v2.1.2
sbom-scorecard	Un punteggio ponderato di conformità alla specifica, informazioni di generazione, e identificatori, versioni e licenze dei pacchetti	Profili dei framework	0.0.7, aprile 2023, l'ultima release

Per ora solo sbomqs verifica i CISA 2026 Minimum Elements. Controlli le note di rilascio di ogni strumento prima di fare affidamento su un profilo: in sbomqs 2.1.1, l'opzione CISA 2026 eseguiva per errore il controllo del 2021. Per BSI TR-03183-2 v2.1.0 in sbomqs, usi --bsi-v21 o --bsi; --bsi-v2 verifica la v2.0.0.

Un passaggio minimo di accettazione per la SBOM CycloneDX di un fornitore:

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

Per SPDX, usi sbomcheck -s spdx3 -c bsi supplier-sbom.json dell'NTIA Conformance Checker. Legga il report di conformità e rifiuti il file sui controlli che il Suo requisito rende obbligatori; lo restituisca al fornitore con i messaggi indicati sopra.

Inserirla nei requisiti per i fornitori

Una checklist che il fornitore non ha mai visto non è un requisito. La inserisca nell'allegato al contratto:

• Il framework e la versione: per esempio «BSI TR-03183-2 v2.1.0» o «CISA 2026 Minimum Elements». Ne citi uno; non scriva «standard di settore».
• Il formato e la versione minima della specifica: per esempio CycloneDX 1.6 o successivo, oppure SPDX 3.0.1 o successivo, in JSON.
• I campi che aggiunge in più, come hash SHA-512 o package URL per ogni pacchetto.
• La consegna: una SBOM per versione software consegnata, prima del software o insieme a esso.
• La validazione che il fornitore esegue prima dell'invio, con strumento e profilo indicati.
• Il ciclo di riscontro: chi riceve i riscontri, ed entro quando è dovuta una SBOM corretta.

Il lato fornitore dello stesso accordo è nella guida SBOM per i fornitori. Per un produttore di software che risponde a una richiesta occasionale, veda le richieste di SBOM dai clienti.

Correggere una SBOM respinta (per i fornitori)

• File scritti a mano. Usi un generatore o una libreria SBOM, mai un editor di testo.
• Package URL mancanti. Li generi dal gestore di pacchetti o dalla build, non a mano. Un purl digitato a mano è un purl indovinato.
• Licenze mancanti. Prenda la licenza dichiarata dai metadati del pacchetto, come identificatore SPDX.
• Nessun hash. Li calcoli sui file che consegna davvero, alla fine della build.
• La release sbagliata. Generi la SBOM nella build di release e le dia il nome della versione.
• Solo il primo livello. Usi un metodo che risolva le dipendenze transitive.

Il modo più affidabile per correggere insieme completezza e identificatori è generare la SBOM dalla build che ha prodotto il software consegnato. Veda SBOM generate in fase di build e best practice SBOM.

Da dove vengono le buone SBOM, e il ruolo di CRACI

Per i fornitori che eseguono le build su GitHub Actions, CRACI sostituisce i runner ospitati da GitHub e registra la SBOM durante la build, così elenca ciò che la build ha effettivamente scaricato.

• Ogni pacchetto con un package URL, e ogni componente con la sua licenza dichiarata.
• Le dipendenze transitive, a ogni livello di profondità raggiunto dalla build.
• Uno stato di completezza per ogni job, che risponde alla domanda sulle incognite note build per build: Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
• Esportazione in CycloneDX o SPDX; la SBOM API restituisce CycloneDX 1.7 in JSON.

Per un'intera organizzazione di ingegneria, veda standardizzare la generazione delle SBOM, e per Linux embedded, perché gli scanner non vedono ciò che c'è nelle build Yocto.

Per gli OEM, le SBOM di terze parti possono essere aggiunte a CRACI, così i componenti acquistati vengono monitorati per nuove vulnerabilità insieme alle Sue build. Veda strumenti di gestione delle SBOM per il confronto.

Quando CRACI non è la risposta

• Validare e valutare le SBOM che riceve. CRACI non offre un validatore di SBOM né un punteggio di qualità. Usi gli strumenti indicati sopra.
• Fornitori senza CI, o il cui codice è generato da strumenti basati su modelli senza download di pacchetti. Un registratore di build aggiunge poco; una SBOM validata prodotta da una libreria di generazione è la risposta realistica.
• Firmware che riceve solo come binario. Qui la risposta è l'analisi binaria.
• SBOM firmate, la firma dell'autore di CISA 2026. CRACI non firma le SBOM.

Qualità e validazione delle SBOM: domande frequenti

Come verifico la qualità di una SBOM inviata da un fornitore?

Verifichi tre livelli. Validi il file rispetto al suo schema, controlli i campi rispetto a un framework preciso come BSI TR-03183-2 o i CISA 2026 Minimum Elements, poi verifichi la completezza: la confronti con un'analisi binaria di ciò che ha ricevuto e cerchi i componenti che il tipo di prodotto deve contenere.

Quali campi deve contenere una SBOM?

Dipende dal framework che cita. I 2026 Minimum Elements della CISA elencano 17 campi, tra cui autore, timestamp, strumento, contesto di generazione e, per ogni componente, nome, versione, produttore, identificatori, hash e licenza. BSI TR-03183-2 aggiunge un hash SHA-512, il nome file e le proprietà del file, e li rende obbligatori.

Che cosa è cambiato tra gli elementi minimi NTIA e i 2026 Minimum Elements della CISA?

L'elenco 2026 della CISA sostituisce i sette campi NTIA con 17. Sono nuovi la firma dell'autore, nome e versione del formato dei dati, contesto di generazione, nome e versione dello strumento, versione della SBOM, valore e algoritmo dell'hash del componente, e licenza del componente. Supplier name è diventato Component Producer, e la profondità è diventata copertura.

Che cosa richiede BSI TR-03183-2 in una SBOM?

La versione 2.1.0 richiede CycloneDX 1.6+ o SPDX 3.0.1+ in JSON o XML, una SBOM per versione del software, dipendenze ricorsive con la loro completezza dichiarata e, per ogni componente, creatore, nome, versione, nome file, licenze, hash SHA-512 e proprietà del file, con un package URL o un CPE se esiste.

Una SBOM ha bisogno di hash? Con quale algoritmo?

La NTIA li raccomandava; CISA 2026 rende l'hash un elemento minimo, con un algoritmo approvato da un'autorità come il NIST; BSI TR-03183-2 richiede lo SHA-512 di ogni componente distribuibile. Chieda SHA-512 e lo confronti con il file ricevuto.

Servono sia un CPE sia un PURL?

Non sempre. Chieda un package URL ovunque l'ecosistema ne abbia uno, e un CPE dove non c'è, come per molti componenti commerciali o embedded. CISA 2026 chiede almeno un identificatore e tutti quelli noti; il BSI richiede ciascuno se esiste.

Come valido un file CycloneDX o SPDX?

Per CycloneDX, cyclonedx-cli validate con --fail-on-errors, oppure sbom-utility. Per SPDX, il comando Verify di SPDX tools-java, oppure pyspdxtools per SPDX 2.2 e 2.3. Poi esegua un profilo di framework con sbomqs o con lo SPDX NTIA Conformance Checker.

Che cos'è un buon punteggio di qualità SBOM?

Non esiste una soglia standard, né un benchmark che citeremmo. Un punteggio misura i campi presenti, non la completezza: un file può ottenere 9 su 10 e mancare metà del prodotto. Fissi piuttosto criteri di accettazione per ogni controllo nel Suo requisito per i fornitori, e segua il punteggio come tendenza.