Come verificare la SBOM ricevuta da un fornitore
Hai chiesto la SBOM (Software Bill of Materials, la distinta base del software) di un componente che integri nei tuoi prodotti, e il fornitore te l'ha mandata. Il lavoro non è finito: una SBOM può essere formalmente valida e inutile nei fatti. Il Cyber Resilience Act (CRA) chiede al fabbricante la dovuta diligenza sui componenti di terzi, e all'importatore di verificare che il fabbricante abbia fatto la sua parte. Qui ci sono dieci controlli che chiunque può fare, senza strumenti e senza essere sviluppatore, e che cosa chiedere quando non passano.
In sintesi
Una SBOM serve a una cosa: sapere, quando esce una vulnerabilità, se e dove tocca il prodotto. Per questo i controlli guardano tre cose, in ordine. Il file è leggibile da un sistema automatico? Dice di quale prodotto e di quale versione parla? Ogni componente è riconoscibile dalle banche dati delle vulnerabilità? Se una risposta è no, la SBOM va rimandata al mittente con una richiesta precisa, non archiviata. Il risultato della verifica si riassume in un giudizio di maturità in quattro gradi: Da verificare, Iniziale, Intermedia, Avanzata.
I dieci controlli
Un file CycloneDX o SPDX è testo: si apre con un editor qualsiasi. I primi quattro controlli riguardano il file, i successivi quattro i componenti, gli ultimi due l'uso nel tempo.
| N. | Controllo | Passa se | Non passa se |
|---|---|---|---|
| 1 | Formato | File CycloneDX o SPDX (JSON o XML) | PDF, foglio di calcolo, tabella in un'e-mail |
| 2 | Data di creazione | Presente e coerente con la versione del componente | Assente, o più vecchia della versione che hai ricevuto |
| 3 | Prodotto e versione descritti | Nome e versione esatti del componente che hai in mano | Solo il nome del prodotto, versione «corrente» o assente |
| 4 | Autore e strumento | Fornitore indicato; strumento di generazione e versione | Nessuna indicazione: probabile compilazione a mano |
| 5 | Versione di ogni componente | Versione precisa per ogni voce (3.0.16) | Versioni vuote o generiche (3.x, «ultima») |
| 6 | Identificativi | Un codice standard per ogni voce (purl o CPE) | Solo nomi in chiaro, scritti in modi diversi |
| 7 | Fornitore di ogni componente | Indicato per ogni voce, con il progetto o l'azienda | Assente, o uguale per tutti |
| 8 | Dipendenze | Dichiarate: si vede quale componente ne tira dentro un altro | Elenco piatto, senza relazioni |
| 9 | Numero plausibile | Decine o centinaia di voci per un firmware con sistema operativo | Dieci voci per un prodotto con sistema operativo e server web |
| 10 | Aggiornamento | Una SBOM per ogni versione rilasciata, con un canale per gli avvisi | Una SBOM sola, «valida per tutte le versioni» |
I controlli 1, 3, 5 e 6 sono quelli che decidono se la SBOM si può usare: senza formato leggibile, senza versione del prodotto, senza versioni e identificativi dei componenti, il confronto automatico con le banche dati fallisce o, peggio, dà risultati sbagliati in silenzio. Il controllo 8 pesa più di quanto sembri: molte vulnerabilità stanno nei componenti indiretti, e una SBOM piatta non li mostra. Un esempio letto riga per riga è nell'articolo sulla SBOM commentata.
Il giudizio di maturità
| Grado | Quando | Che cosa farne |
|---|---|---|
| Da verificare | Non passa uno dei controlli 1, 3, 5 o 6 | Non è utilizzabile. Si rimanda al fornitore con la richiesta dei campi mancanti. |
| Iniziale | Passa i controlli decisivi, ma manca almeno uno tra fornitore, dipendenze e numero plausibile | Si usa per il confronto con le vulnerabilità, sapendo che una parte dei componenti non si vede. Si chiede il completamento al prossimo rilascio. |
| Intermedia | Passa i primi nove, con le dipendenze di primo livello | È il livello che soddisfa la lettera del regolamento. Si collega ai propri prodotti e si segue nel tempo. |
| Avanzata | Passa tutti e dieci, generata dalla build, con dipendenze profonde e impronte dei file | Nessuna richiesta. Si concorda solo il canale per gli aggiornamenti e per gli avvisi. |
Un caso concreto
Un costruttore di macchine integra in un impianto tre componenti digitali di tre fornitori: un controllore, un pannello operatore e un router per l'assistenza remota. I dati sono di fantasia. Chiede le tre SBOM e riceve:
- dal fornitore del controllore, un PDF con l'elenco di 15 componenti: non passa il controllo 1, giudizio Da verificare. Il costruttore risponde chiedendo un file CycloneDX o SPDX per la versione del firmware installata;
- dal fornitore del pannello, un file CycloneDX con 80 componenti, tutti senza versione e senza dipendenze: non passa i controlli 5 e 8, giudizio Da verificare. Chiede versioni e identificativi;
- dal fornitore del router, un file CycloneDX generato dalla build, con 210 componenti, versioni, identificativi e dipendenze: giudizio Avanzata. Concorda di ricevere la nuova SBOM a ogni versione del firmware.
Una SBOM su tre è utilizzabile. È una proporzione normale: in un'indagine europea del 2026 il 78% delle organizzazioni riceve le SBOM dai fornitori «mai» o «raramente» (ENISA, 2026). Il punto non è lamentarsene, ma chiedere la cosa giusta.
Che cosa chiedere al fornitore
Una richiesta precisa ottiene più di un sollecito generico. Sei punti da mettere per iscritto, nel contratto per le forniture nuove e in una lettera per quelle in corso:
- formato CycloneDX o SPDX, in JSON o XML;
- una SBOM per ogni versione del firmware o del software fornito, con la versione indicata nel file;
- per ogni componente: nome, versione, fornitore, identificativo standard e licenza;
- dipendenze dichiarate, almeno di primo livello;
- nuova SBOM a ogni rilascio, e un canale per gli avvisi di sicurezza sulle vulnerabilità che toccano il componente;
- un accordo di riservatezza, se il fornitore lo chiede, al posto di un rifiuto.
Come riferimento tecnico si può citare la linea guida tedesca BSI TR-03183-2, che elenca i campi richiesti e che molti fornitori europei già conoscono.
Se il fornitore non la fornisce
Capita, soprattutto con fornitori extra-UE o con componenti vecchi. Le strade sono tre, in ordine di preferenza.
- Clausola per il futuro. Si inserisce la SBOM tra i requisiti di acquisto delle forniture nuove. Dall'11 dicembre 2027 il fornitore che vende nell'Unione ha comunque l'obbligo di averla.
- Componente come unità. Nella propria SBOM si dichiara il componente con nome, versione e fornitore, senza il dettaglio interno, e si seguono gli avvisi di sicurezza del fornitore. È un rimedio, non una soluzione: le vulnerabilità delle librerie interne restano invisibili.
- Analisi del firmware. Strumenti di analisi del file binario ricostruiscono un elenco dei componenti, con una precisione minore di quella della build. Richiede competenze o un servizio esterno.
Per un importatore il discorso è più stretto: deve verificare che il fabbricante abbia redatto la documentazione tecnica, e un fabbricante che non sa fornire la SBOM è un segnale da annotare. La guida per importatori e distributori elenca gli altri controlli.
Domande frequenti
Il fornitore dice che la SBOM è riservata. È una risposta valida?
È una risposta frequente e si supera con un accordo di riservatezza. Il regolamento non obbliga il fornitore a rendere pubblica la SBOM, ma chi integra il componente in un prodotto proprio ha bisogno di conoscerne il contenuto per la propria dovuta diligenza.
La SBOM ricevuta si riferisce a una versione diversa da quella installata. Si può usare?
No. Una SBOM vale per una versione precisa; tra una versione e l'altra i componenti cambiano. Va chiesta quella della versione effettivamente in uso, e poi una per ogni aggiornamento.
Gli stessi controlli valgono per la SBOM dei nostri prodotti?
Sì, e conviene farli prima che li faccia un cliente. La differenza è che la propria SBOM si genera dalla build, non si chiede a nessuno. Che cosa prevede il regolamento è nell'articolo La SBOM è obbligatoria?.
Da dove cominciare
I dieci controlli sono la stessa verifica che Assiduo fa nell'Inquadramento, su tutte le SBOM dei tuoi prodotti e dei tuoi fornitori, e il giudizio di maturità è quello che trovi nel rapporto sulla tua situazione CRA. Il configuratore, prima e senza caricare file, stima da poche domande a che punto sei con le SBOM.
Fonti: regolamento (UE) 2024/2847, articolo 13 paragrafo 5, articolo 19, Allegato I Parte II punto 1; BSI TR-03183-2; CycloneDX (ECMA-424) e SPDX (ISO/IEC 5962); ENISA, «SBOM Adoption State of Play 2026». Consultate il 14 ottobre 2026. Leggi anche: la guida alla SBOM e la guida per i costruttori di macchine.