SBOM (distinta base del software) — cosa richiede il Cyber Resilience Act

Una distinta base del software è un artefatto noioso con conseguenze sproporzionate. È un elenco: da quali componenti è costruito il software di un prodotto, in quali versioni, da quali fornitori, con quali licenze. Fino a poco tempo fa era una comodità interna del gruppo di ingegneria. Con il regolamento (UE) 2024/2847 — il Cyber Resilience Act — diventa un requisito essenziale, e per di più uno che le autorità di vigilanza del mercato possono chiedere di vedere.

La ragione è semplice. Quando viene pubblicata una vulnerabilità in una libreria molto diffusa, conta una sola domanda: siamo interessati? Senza una distinta base la risposta costa settimane di archeologia manuale tra repository e server di compilazione. Con la distinta base costa una query. Il CRA trasforma questa realtà operativa in un obbligo giuridico — e, come per quasi tutti gli obblighi sui dati di prodotto, la questione non è tanto scrivere un documento una volta quanto mantenere i dati veri attraverso ogni rilascio per un decennio. È la stessa disciplina che il passaporto digitale del prodotto richiede in altri ambiti del diritto dei prodotti dell’UE.

I punti chiave

L’obbligo di SBOM si trova nell’allegato I parte II del CRA, tra i requisiti di gestione delle vulnerabilità. Si applica integralmente dall’11 dicembre 2027.
La soglia giuridica è modesta: un formato di uso comune e leggibile automaticamente, che copra almeno le dipendenze di primo livello, mantenuto aggiornato. Il regolamento non indica alcun formato specifico.
In pratica significa CycloneDX (OWASP, normato come ECMA-424) oppure SPDX (Linux Foundation, ISO/IEC 5962:2021). I tag SWID (ISO/IEC 19770-2) sono un identificatore per la gestione degli asset software, non un inventario completo delle dipendenze.
Non esiste alcun obbligo di pubblicare la SBOM ai clienti. Va messa a disposizione delle autorità di vigilanza del mercato su richiesta e fa parte della documentazione tecnica dell’allegato VII.
La documentazione tecnica va tenuta a disposizione delle autorità per almeno dieci anni dall’immissione del prodotto sul mercato, o per il periodo di assistenza se più lungo.
La tedesca BSI TR-03183-2 va ben oltre la soglia del CRA: richiede la risoluzione ricorsiva dell’intero albero delle dipendenze, hash SHA-512 e un insieme di campi definito. Non è diritto vincolante, ma è il riferimento pubblicato più concreto e gli acquirenti lo citano sempre più spesso.
Una SBOM non legata a una versione precisa del prodotto non prova nulla. Versionare invece di sovrascrivere è tutto il punto.
Il CRA non richiede una SBOM nel passaporto digitale del prodotto. Richiede dati di prodotto a livello di versione che sopravvivano un decennio — lo stesso problema, risolto con gli stessi strumenti.

Cosa è davvero una SBOM

Tolto l’acronimo, una SBOM è un inventario con provenienza. Per ogni componente che finisce nel prodotto consegnato registra almeno come si chiama il componente, quale versione ha e chi lo ha fornito. Le distinte migliori aggiungono la licenza, un hash crittografico che permette di identificare il componente senza ambiguità e le relazioni di dipendenza — quale componente ne ha trascinato quale altro.

La distinzione che conta di più è la profondità. Una SBOM di primo livello elenca ciò che il codice dichiara direttamente: le dodici librerie del file di manifesto. Una SBOM transitiva risolve ciò che quelle dodici si portano dietro, e ciò che quelle a loro volta si portano dietro, fino alle foglie dell’albero. In applicazioni reali dodici dipendenze dichiarate diventano abitualmente diverse centinaia di dipendenze effettive. Le vulnerabilità si annidano quattro livelli più in basso con la stessa facilità con cui stanno in superficie — ed è proprio per questo che la distanza tra la soglia del CRA e il contenuto di una SBOM utile non è accademica.

La seconda distinzione è quando viene generata. Una SBOM generata dal codice sorgente descrive ciò che gli sviluppatori intendevano. Una SBOM generata dall’output della compilazione descrive ciò che è stato effettivamente rilasciato, compresi i componenti immessi dal sistema di build, dall’immagine base del contenitore o dal binario di un fornitore. Le due divergono più spesso di quanto i gruppi si aspettino, e solo la seconda vale come prova.

Cosa richiede il CRA — e cosa no

L’allegato I parte II del regolamento (UE) 2024/2847 stabilisce i requisiti di gestione delle vulnerabilità che un fabbricante deve soddisfare per tutto il periodo di assistenza. Il primo è la distinta base: i fabbricanti devono individuare e documentare i componenti contenuti nel prodotto, anche redigendo una distinta base del software in un formato di uso comune e leggibile automaticamente che copra almeno le dipendenze di primo livello, e tenerla aggiornata.

Tre elementi di questa frase meritano una lettura attenta.

«Formato di uso comune e leggibile automaticamente». Il regolamento non nomina deliberatamente alcun formato. È prassi consolidata nel diritto dei prodotti dell’UE: il testo giuridico enuncia la proprietà, le norme armonizzate forniscono il dettaglio tecnico. In pratica il campo si è condensato su due formati, ed entrambe le scelte sono difendibili.

«Almeno le dipendenze di primo livello». È un minimo, non un obiettivo. La legge non obbliga a risolvere l’intero albero transitivo. Non impedisce però a un’autorità, a un organismo di certificazione o a un grande cliente aziendale di chiedere di più — e non rende utile una SBOM limitata al primo livello per lo scopo per cui esiste. Trattate la soglia come il minimo di conformità e l’albero transitivo come il requisito operativo.

«Tenerla aggiornata». L’obbligo è continuativo e corre per tutto il periodo di assistenza. Una distinta redatta una volta per il fascicolo tecnico e mai rigenerata diverge dalla realtà al primo rilascio correttivo.

Altrettanto importante è ciò che il CRA non richiede:

Nessun obbligo di pubblicazione. Rendere pubblica la SBOM è una decisione commerciale. L’obbligo giuridico è metterla a disposizione della vigilanza del mercato su richiesta. Alcuni settori e grandi acquirenti la pretenderanno contrattualmente: è un’altra pressione, non giuridica.
Nessun formato né profilo imposto. Nessun obbligo di CycloneDX contro SPDX, nessun elenco minimo di campi nel regolamento stesso.
Nessuna SBOM nel passaporto di prodotto. Il CRA non crea passaporto, né supporto dati, né registro.

Formati: CycloneDX, SPDX e SWID

	CycloneDX	SPDX	Tag SWID
Origine	OWASP	Linux Foundation	ISO/IEC
Norma	ECMA-424	ISO/IEC 5962:2021	ISO/IEC 19770-2
Progettato per	sicurezza applicativa	conformità delle licenze e provenienza	gestione degli asset software
Punto di forza tipico	flussi sulle vulnerabilità, CI/CD, VEX	livello di file e frammento, acquisti	identificazione del software installato
Inventario completo delle dipendenze	sì	sì	non è il suo scopo

CycloneDX nasce dalla comunità della sicurezza applicativa ed è stato costruito fin dall’inizio per casi d’uso di sicurezza. Il suo vantaggio pratico è l’ecosistema che lo circonda: si estende a distinte di hardware, SaaS, apprendimento automatico e crittografia, e trasporta VEX — Vulnerability Exploitability eXchange —, che permette di dichiarare che una vulnerabilità nota in un componente elencato non è in realtà sfruttabile nel proprio prodotto. Per un fabbricante con obblighi di gestione delle vulnerabilità sotto il CRA, poter dire «presente ma non sfruttabile, ed ecco perché» in forma leggibile automaticamente vale moltissimo lavoro risparmiato.

SPDX nasce dalla conformità delle licenze e porta quell’eredità come profondità: descrive il software fino ai singoli file e frammenti di codice, ed è la scelta naturale quando il requisito è guidato da acquisti, revisione legale e documentazione formale.

I tag SWID compaiono in quasi tutti i confronti tra formati e in alcune linee guida ufficiali, ma risolvono un problema diverso: identificare il software installato su una macchina. Non sostituiscono un inventario delle dipendenze.

La risposta onesta sulla scelta: i due formati principali stanno convergendo, gli strumenti supportano entrambi e i convertitori esistono. Scegliete quello che la vostra catena di strumenti attuale genera in modo più affidabile e standardizzatevi su quello. Una SBOM rotta nel formato «migliore» è peggio di una corretta in uno qualsiasi dei due.

I campi di dati — tre riferimenti

Il CRA fissa un minimo. Tre documenti pubblicati dicono cosa contiene davvero una SBOM seria.

Il riferimento tedesco: BSI TR-03183-2

L’ufficio federale tedesco per la sicurezza informatica pubblica la Linea guida tecnica TR-03183: requisiti di resilienza informatica per fabbricanti e prodotti, parte 2: distinta base del software (SBOM). Non è diritto vincolante, ma è la specifica pubblica più concreta scritta espressamente contro il CRA, e viene citata sempre più spesso nei questionari tedeschi ai fornitori. La versione 2.1.0 è stata pubblicata nell’agosto 2025.

Richiede serializzazione in JSON o XML, in CycloneDX versione 1.6 o superiore oppure SPDX versione 3.0.1 o superiore. I campi si dividono in tre categorie: obbligatori (sempre), aggiuntivi (obbligatori quando il dato sottostante esiste) e facoltativi.

Obbligatori a livello di documento:

creatore della SBOM — indirizzo e-mail o URL che identifichi il produttore,
marca temporale in formato ISO 8601.

Obbligatori per ciascun componente:

nome del componente,
versione del componente,
creatore del componente, cioè il fornitore,
nome del file del componente,
dipendenze da altri componenti — risolte in modo ricorsivo,
licenze di distribuzione,
hash del componente distribuibile, SHA-512,
se il componente è eseguibile, se è un archivio, se è strutturato.

Notate la distanza rispetto al testo del CRA. La risoluzione ricorsiva dell’intero albero è sensibilmente più lavoro delle dipendenze di primo livello, e il requisito SHA-512 costringe a generare la SBOM da artefatti di compilazione reali e non da un file di manifesto. Se vendete sul mercato tedesco, pianificate rispetto a questo riferimento e non rispetto alla soglia del regolamento.

La linea di base statunitense: elementi minimi NTIA

Il documento NTIA Minimum Elements for a Software Bill of Materials del 2021 ha definito sette campi di base a cui gran parte degli strumenti punta ancora oggi: nome del fornitore, nome del componente, versione, altri identificatori univoci, relazione di dipendenza, autore dei dati SBOM e marca temporale. Le linee guida statunitensi sono state poi riviste — la CISA ha svolto una consultazione pubblica su un insieme aggiornato di elementi minimi che aggiunge campi come hash del componente, licenza e contesto di generazione. Se già producete SBOM per clienti federali statunitensi siete vicini alla soglia del CRA; non siete ancora al riferimento tedesco.

Le norme armonizzate, ancora in corso

La richiesta di normazione della Commissione per il CRA è stata accettata da CEN, CENELEC ed ETSI il 3 aprile 2025 e copre un programma di norme orizzontali e verticali. Qui rileva la serie orizzontale EN 40000, in particolare la norma sulla gestione delle vulnerabilità, dove la pratica della SBOM verrà precisata. Al momento in cui scriviamo queste norme sono ancora in fase di redazione e approvazione, e la Commissione ha ipotizzato di spostare in avanti i termini di consegna.

La conseguenza pratica: non aspettate la norma armonizzata. Il suo contenuto viene redatto sullo stesso testo dell’allegato I, e il lavoro operativo — strumentare la build perché emetta una SBOM a ogni rilascio — non cambia a seconda di quale elenco di campi prevarrà. Aspettare costa l’anno di storico dei rilasci che altrimenti si avrebbe già.

Dove le SBOM falliscono nella pratica

Generata a mano, una volta sola

Il fallimento più comune è un foglio di calcolo messo insieme per il fascicolo tecnico, esportato in JSON e mai più toccato. È esatto il giorno in cui viene scritto e sbagliato al primo aggiornamento di versione di una dipendenza. L’obbligo del CRA è tenere aggiornata la distinta, quindi una SBOM obsoleta non è un adempimento parziale: è un inadempimento documentato di un obbligo continuativo.

Non legata a una versione

Una SBOM senza indicazione inequivocabile di quale prodotto, quale versione e quale build descriva non prova nulla. Quando un’autorità chiederà se le unità spedite nel marzo 2028 contenevano una libreria vulnerabile, servirà la distinta di quella build, non quella attuale. È l’errore strutturale più diffuso, ed è un problema di modellazione dei dati, non di sicurezza.

Costruita dal codice, non dall’artefatto

I file di manifesto descrivono le intenzioni. L’artefatto consegnato contiene ciò che la build ha prodotto: l’immagine base, la libreria collegata staticamente, l’SDK del fornitore inserito come binario. Le SBOM generate solo dal sorgente sottostimano sistematicamente, e i componenti che omettono sono in misura sproporzionata proprio quelli che nessuno aggiorna.

Componenti di terzi e integrati mancanti

Se un fornitore vi consegna un modulo, i suoi componenti sono nel vostro prodotto. Al CRA non interessa che non li abbiate scritti voi. Ottenere SBOM dai fornitori è un problema di approvvigionamento con tempi lunghi: i contratti vanno modificati e i piccoli fornitori spesso non hanno alcuna capacità. È la voce da cui conviene partire prima.

Nessun posto dove conservarla

Una SBOM per ogni rilascio, conservata dieci anni o per il periodo di assistenza, su tutte le famiglie di prodotto, è un insieme di dati versionato che deve sopravvivere a migrazioni di strumenti, spostamenti di repository e all’uscita di chi lo ha impostato. Un artefatto di build in un sistema di CI che verrà sostituito tra tre anni non è una strategia di conservazione.

Integrare la generazione della SBOM nel processo di rilascio — cinque passi

Generare dalla build, automaticamente. Aggiungete la generazione della SBOM alla fase della pipeline che produce l’artefatto consegnabile, così che non possa esistere una SBOM senza build né una build senza SBOM. La generazione manuale devia sempre.
Legare la SBOM a un’identità. Prodotto, versione, identificativo di build, marca temporale. È ciò che trasforma un file in una prova, ed è il passo che i gruppi saltano più spesso.
Fissare profondità e formato, e metterlo per iscritto. Decidete CycloneDX o SPDX, decidete se risolvere in modo transitivo (dovreste) e documentate la decisione perché sei cicli di rilascio più tardi nessuno la cambi in silenzio.
Spingere il requisito a monte nella catena di fornitura. Modificate gli accordi con i fornitori per esigere una SBOM per ogni versione consegnata, nel formato scelto. Cominciate dai fornitori dei componenti che non potete ispezionare.
Conservarla dove sarà ancora leggibile fra un decennio. Versionata, indicizzata per prodotto e rilascio, recuperabile senza il sistema di build originale. La conservazione è il requisito che sopravvive a ogni strumento usato per soddisfarlo.

Il programma di dati più ampio in cui tutto questo si inserisce è trattato nella nostra checklist di implementazione del DPP.

Cosa significa per i dati di prodotto

Tracciamo il confine con chiarezza: il CRA non mette una SBOM nel passaporto digitale del prodotto. Il regolamento non contiene alcun obbligo di passaporto, e nessuna lettura trasforma una distinta base in un campo pubblico. Gli obblighi di passaporto vengono dall’ESPR e dagli atti settoriali che li impongono espressamente.

Ciò che i due regimi condividono è la forma. Entrambi richiedono dati che siano:

legati a una versione, non a una linea di prodotto. La SBOM cambia a ogni rilascio, esattamente come i dati del passaporto cambiano a ogni revisione di specifica. I sistemi che sovrascrivono il record corrente non possono rispondere a una domanda su un’unità venduta tre anni fa;
leggibili automaticamente per progetto. Non un PDF che per caso contiene una tabella, ma un documento strutturato che un altro sistema possa elaborare senza una persona in mezzo;
conservati per un decennio. Dieci anni di documentazione tecnica sotto il CRA sono lo stesso impegno infrastrutturale della disponibilità a lungo termine del passaporto sotto l’ESPR;
coerenti tra i canali. La data di fine assistenza, il punto di contatto per le vulnerabilità e le informazioni sugli aggiornamenti devono dire la stessa cosa nel vostro negozio, presso un distributore e nella documentazione.

Per l’elettronica l’argomento si somma. Lo stesso prodotto ricade contemporaneamente sotto l’ESPR, la direttiva RoHS, la direttiva RAEE e il CRA. Un’azienda che tiene i dati sulle sostanze in un sistema, quelli sulla riparabilità in un altro e quelli sui componenti software in un terzo mantiene quattro registri su un solo prodotto. L’argomento di fondo per trattare i dati di prodotto come infrastruttura è in DPP e PIM, e il raccordo con la marcatura è in marcatura CE e passaporto digitale.

Una nota onesta su dove si ferma una piattaforma di passaporti: myDPP non genera SBOM, non scansiona codice né contenitori, non valida una distinta base rispetto a una build, non svolge analisi delle vulnerabilità e non valuta la conformità al CRA. Questo appartiene alla vostra catena di strumenti di ingegneria e, dove richiesto, a un organismo notificato. Ciò che una piattaforma di passaporti fa è conservare dati di prodotto versionati, mantenerli recuperabili per anni e pubblicare le parti destinate a essere pubbliche. La responsabilità della conformità resta del fabbricante.

Calendario

Data	Cosa accade
10 dicembre 2024	entra in vigore il regolamento (UE) 2024/2847
3 aprile 2025	CEN, CENELEC ed ETSI accettano la richiesta di normazione
11 giugno 2026	si applicano le disposizioni sugli organismi notificati
11 settembre 2026	si applicano gli obblighi di segnalazione — anche per i prodotti già sul mercato
11 dicembre 2027	applicazione integrale — il requisito SBOM dell’allegato I diventa vincolante

L’obbligo di segnalazione arriva più di un anno prima dell’obbligo di SBOM, e questo ordine è istruttivo. Da settembre 2026 potreste dover segnalare una vulnerabilità attivamente sfruttata entro 24 ore. Rispondere «quali dei nostri prodotti contengono questo componente» dentro quella finestra è esattamente il problema per cui una SBOM esiste — il che colloca la scadenza pratica ben prima di quella giuridica.

Domande frequenti

Devo pubblicare la mia SBOM?

No. Il CRA obbliga a redigerla, tenerla aggiornata e metterla a disposizione delle autorità di vigilanza del mercato su richiesta. Entra a far parte della documentazione tecnica. Pubblicarla ai clienti è una scelta commerciale — e sempre più una richiesta contrattuale dei grandi acquirenti, cosa distinta dall’obbligo giuridico.

Basta un elenco di dipendenze di primo livello?

Soddisfa la lettera dell’allegato I parte II. Non soddisfa la BSI TR-03183-2 tedesca, che richiede la risoluzione ricorsiva dell’albero delle dipendenze, e non risponderà alla domanda a cui dovrete davvero rispondere quando una vulnerabilità comparirà quattro livelli più in basso. Il primo livello è il minimo, il transitivo è l’obiettivo.

CycloneDX o SPDX?

Sotto il CRA, che non nomina formati, entrambi sono difendibili. CycloneDX ha l’ecosistema di sicurezza più forte e trasporta VEX; SPDX ha maggiore profondità per il lavoro su licenze e provenienza. La BSI TR-03183-2 accetta CycloneDX 1.6+ o SPDX 3.0.1+. Il fattore decisivo dovrebbe essere quale dei due la vostra catena di strumenti produce in modo affidabile.

Per quanto tempo devo conservare le SBOM?

La SBOM fa parte della documentazione tecnica, che va tenuta a disposizione delle autorità di vigilanza del mercato per almeno dieci anni dall’immissione del prodotto sul mercato, o per la durata del periodo di assistenza se più lungo. Poiché ogni rilascio genera una nuova SBOM, si tratta di un archivio versionato e non di un singolo file.

Una SBOM va nel passaporto digitale del prodotto?

Giuridicamente no. Il CRA non crea obblighi di passaporto e nessun atto sul passaporto attualmente in vigore richiede una distinta base come campo dati. La sovrapposizione è nell’infrastruttura: entrambi hanno bisogno di dati di prodotto a livello di versione, leggibili automaticamente, conservati per un decennio e raggiungibili tramite un identificatore stabile.

Continua a leggere

Fonti

Regolamento (UE) 2024/2847 — Cyber Resilience Act — EUR-Lex
The Cyber Resilience Act — sintesi del testo legislativo — Commissione europea
BSI TR-03183-2: Software Bill of Materials (SBOM) — Bundesamt für Sicherheit in der Informationstechnik
CycloneDX — ECMA-424 — OWASP
SPDX — ISO/IEC 5962:2021 — Linux Foundation
Minimum Elements for a Software Bill of Materials — CISA