Requisiti SBOM del CRA: formato, ambito, aggiornamenti e conservazione
Il CRA impone a ogni prodotto con elementi digitali di essere accompagnato da una Software Bill of Materials (SBOM) leggibile da macchina, che elenchi i suoi componenti software e copra almeno le loro dipendenze di primo livello. Lo SBOM si trova nella documentazione tecnica e deve essere pronto per un'autorità di vigilanza del mercato su richiesta, non depositato in anticipo.
Riepilogo
- Ogni prodotto con elementi digitali richiede uno SBOM leggibile da macchina come parte dell'evidenza sulla gestione delle vulnerabilità. È obbligatorio, senza alcuna deroga legata alle dimensioni.
- Il minimo legale sono le dipendenze di primo livello. La copertura transitiva è una pratica più solida ed è ciò che si aspettano la maggior parte dei framework di qualità SBOM.
- Un prodotto significa un unico corpo di evidenza SBOM, anche quando è costruito a partire da molti repository o componenti.
- Mantieni lo SBOM aggiornato durante il periodo di assistenza, soprattutto dopo release, cambi di componenti e decisioni sulle vulnerabilità.
- Conserva lo SBOM con la documentazione tecnica per almeno 10 anni, o per il periodo di assistenza se più lungo.
- L'obbligo di segnalazione delle vulnerabilità inizia l'11 settembre 2026; l'applicazione integrale del CRA è l'11 dicembre 2027.
Cos'è uno SBOM?
Una Software Bill of Materials (SBOM) è un inventario strutturato del software contenuto in un prodotto: librerie, framework, pacchetti del sistema operativo e le dipendenze tra di essi. Per il CRA è il registro che un'autorità di vigilanza del mercato userebbe per verificare quali dei suoi componenti sono interessati da una vulnerabilità segnalata, perciò deve essere leggibile da macchina e non un documento in prosa.
Cosa richiede il CRA in uno SBOM
L'obbligo SBOM ha due livelli pratici: cosa deve coprire l'inventario e dove deve stare l'evidenza nel fascicolo tecnico.
Quali componenti deve coprire lo SBOM?
I fabbricanti devono identificare e documentare i componenti e le vulnerabilità dei loro prodotti con elementi digitali, e redigere uno SBOM in un formato di uso comune e leggibile da macchina che copra almeno le dipendenze di primo livello del prodotto.
Ciò significa:
- Lo SBOM deve essere leggibile da macchina e in un formato di uso comune. Un PDF o un foglio di calcolo può aiutare le persone a esaminare l'inventario, ma non sostituisce il file SBOM.
- Deve coprire almeno le dipendenze di primo livello. La copertura transitiva va oltre il minimo legale ed è la base migliore per il monitoraggio delle vulnerabilità.
Ogni prodotto con elementi digitali immesso sul mercato UE deve avere uno SBOM leggibile da macchina. Non esiste alcuna deroga né soglia dimensionale al di sotto della quale l'obbligo venga meno. Il livello di dettaglio che documenti si commisura al rischio del prodotto, ma l'obbligo di redigere uno SBOM no.
Al momento le regole chiedono soltanto un formato di uso comune e leggibile da macchina che copra almeno le dipendenze di primo livello. Non indicano un formato specifico né un elenco fisso di campi. Quel minimo può essere innalzato: il CRA lascia alla Commissione la possibilità di definire più avanti un formato SBOM preciso e un insieme di campi. Scegliere adesso un formato ben supportato, CycloneDX o SPDX, e raccogliere più del minimo indispensabile è la copertura più sicura contro un futuro formato prescritto.
Dove si colloca lo SBOM nel fascicolo tecnico
Lo SBOM fa parte della tua documentazione tecnica, depositato accanto al resto dell'evidenza sulla gestione delle vulnerabilità: la politica di divulgazione coordinata delle vulnerabilità, un indirizzo di contatto per le segnalazioni e il modo in cui distribuisci gli aggiornamenti in modo sicuro. Non lo trasmetti in anticipo. Deve esistere quando il prodotto è immesso sul mercato UE ed essere pronto per un'autorità di vigilanza del mercato in caso di richiesta motivata.
In pratica, lo SBOM dovrebbe consentire il tracciamento delle vulnerabilità a livello di componente, i controlli su fornitore e origine, la revisione delle licenze e la pianificazione di fine vita.
Quanti SBOM servono per un prodotto?
Un prodotto è spesso costruito a partire da molti repository e componenti, e ciascuno può emettere il proprio SBOM. Il CRA fissa l'unità di evidenza sul prodotto, non sul repository né sulla build.
Il CRA definisce uno SBOM come un registro dei componenti del software di un prodotto e di come si relazionano tra loro, e si aspetta che quel registro copra almeno le dipendenze di primo livello del prodotto. L'oggetto dell'evidenza è il prodotto che immetti sul mercato UE, identificato da prodotto e versione. Un prodotto assemblato a partire da dieci repository non è coperto da dieci SBOM di componenti scollegati che nulla tiene insieme. Devi un'evidenza SBOM che rappresenti il prodotto così come è stato consegnato.
Il CRA non impone un unico file fisico e non vieta di conservare gli SBOM dei componenti. Due strade funzionano entrambe, purché il risultato sia leggibile da macchina, stia a livello di prodotto e copra almeno le dipendenze di primo livello:
- Comporre. Conserva gli SBOM dei componenti come documenti separati e collegali in uno SBOM del prodotto, usando i componenti di assembly di CycloneDX con riferimenti BOM-Link, oppure le relationship di SPDX con riferimenti a documenti esterni.
- Unire. Appiattisci ogni componente in un unico documento CycloneDX o SPDX per la versione del prodotto.
Poiché lo SBOM è destinato a catturare come i componenti si relazionano, un elenco piatto di nomi di pacchetto non basta da solo. Qualunque strada tu scelga, lo SBOM dovrebbe mostrare come i componenti dipendono l'uno dall'altro e si contengono a vicenda, cosa che forniscono sia i grafi delle dipendenze di CycloneDX sia le relationship di SPDX. Per i dettagli sui meccanismi di formato, consulta CycloneDX vs SPDX.
Chi deve ricevere lo SBOM?
Lo SBOM è materiale del fascicolo tecnico, non un documento pubblico. Il CRA non ti obbliga a pubblicarlo, e l'unico soggetto che può esigerlo è un'autorità di vigilanza del mercato, che può richiederlo con una richiesta motivata quando deve verificare la tua conformità. Condividere lo SBOM con gli utilizzatori è facoltativo. Se scegli di condividerlo con gli utilizzatori, devi poi indicare loro dove trovarlo.
| Chi | Cosa si aspetta il CRA |
|---|---|
| Autorità di vigilanza del mercato | Può richiedere lo SBOM con una richiesta motivata, quando serve per verificare la conformità |
| Utilizzatori e pubblico | Nessun obbligo di pubblicarlo o consegnarlo; la condivisione è una tua scelta |
| Importatori e distributori | Nessun diritto allo SBOM in sé; devono poter fornire la tua documentazione tecnica alle autorità su richiesta |
| Integratori che costruiscono sul tuo prodotto | Quando il tuo prodotto è destinato a essere integrato nel loro, fornisci loro le informazioni necessarie per adempiere ai propri obblighi, che non sono automaticamente l'intero SBOM |
Non pubblicare lo SBOM né inviarlo agli utilizzatori per impostazione predefinita. Uno SBOM è una mappa precisa dei tuoi componenti e delle loro versioni, esattamente ciò che vuole un attaccante, e il CRA non ti impone alcun obbligo di distribuirlo ampiamente. Mettilo a disposizione di un'autorità di vigilanza del mercato quando presenta una richiesta motivata, e dei clienti business che costruiscono sul tuo prodotto, sotto NDA o contratto, perché ne hanno bisogno per assemblare il proprio SBOM a livello di prodotto e adempiere ai propri obblighi. Tieni traccia di chi ha ricevuto quale versione.
Cosa deve contenere lo SBOM
Separa il minimo legale del CRA dai campi che rendono lo SBOM utile nei flussi reali di gestione delle vulnerabilità. Il regolamento stabilisce il minimo. TR-03183, gli strumenti CycloneDX/SPDX e le aspettative dei clienti di solito alzano l'asticella operativa.
| Area | Minimo CRA | Implementazione solida |
|---|---|---|
| Formato | Di uso comune e leggibile da macchina | CycloneDX JSON/XML o SPDX JSON/tag-value, generato dagli strumenti di build |
| Ambito | Almeno dipendenze di primo livello | Dipendenze dirette e transitive, librerie interne, firmware e pacchetti OS ove applicabile |
| Componenti | Componenti contenuti nel prodotto | Nome, versione, fornitore, PURL o CPE, hash e dati di relazione |
| Vulnerabilità | Componenti e vulnerabilità identificati e documentati | Stato attuale delle vulnerabilità, decisione VEX o di sfruttabilità, riferimento di correzione e data di revisione |
| Evidenza del fascicolo tecnico | SBOM incluso nell'evidenza del processo di gestione delle vulnerabilità | Riferimento stabile del file per versione prodotto, strumento di generazione, data di generazione e risultato di validazione |
| Accesso delle autorità | Disponibile dove necessario per una richiesta motivata di vigilanza del mercato | Archivio sicuro con responsabile del recupero, controlli di integrità e copertura del periodo di assistenza |
Il CRA ti impone di identificare e documentare le vulnerabilità, ma questo non significa che i dati sulle vulnerabilità o VEX debbano stare dentro il file SBOM stesso. Includerli lì è una buona pratica, non un minimo. Per i requisiti sui campi che vanno oltre questa checklist (identificatori PURL, valori hash, metadati del documento), consulta come BSI TR-03183 estende il CRA. Per un confronto tra strumenti CycloneDX e SPDX, consulta CycloneDX vs SPDX.
Come si presenta una sintesi SBOM del fascicolo tecnico
Un fascicolo tecnico solido affianca allo SBOM leggibile da macchina un breve registro di sintesi. La sintesi è una copertina per la revisione umana. Lo SBOM vero e proprio è il file CycloneDX o SPDX allegato a cui rimanda.
SINTESI SBOM DEL FASCICOLO TECNICO
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generazione), Trivy (scansione)
FILE SBOM:
sbom-ssp3000-v2.4.1.json (allegato, leggibile da macchina)
SINTESI DEI COMPONENTI:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
Per tipo:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
STATO DELLE VULNERABILITÀ ALLA VALUTAZIONE:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accettate - vedi sotto)
VULNERABILITÀ ACCETTATE:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: Non sfruttabile nella nostra configurazione
Justification: Funzionalità non abilitata, code path non raggiungibile
Review Date: 2027-04-15
-------------------------------------------------------------
Quando aggiornare lo SBOM
Lo SBOM non è un documento una tantum. La tua documentazione tecnica deve essere redatta prima dell'immissione del prodotto sul mercato e mantenuta aggiornata, ove appropriato, almeno per tutto il periodo di assistenza. Il periodo di assistenza riflette la durata di utilizzo prevista del prodotto, ed è di almeno cinque anni, salvo che il prodotto sia realmente destinato a un uso più breve.
Rivedi o rigenera lo SBOM quando:
| Trigger | Cosa cambia | Azione pratica |
|---|---|---|
| Nuova versione firmware o software | Nuovo artefatto di build | Rigenerare lo SBOM per quella versione del prodotto |
| Patch di sicurezza | Cambia la versione di un componente | Aggiornare i componenti interessati e archiviare il nuovo SBOM |
| Vulnerabilità scoperta e valutata | Cambia lo stato VEX o di sfruttabilità | Aggiornare lo stato e l'evidenza della decisione |
| Componente aggiunto, rimosso o sostituito | Cambia il grafo delle dipendenze | Rigenerare e validare lo SBOM |
| Modifica progettuale rilevante per la sicurezza | Cambiano componenti o architettura | Rigenerare lo SBOM e aggiornare i riferimenti del fascicolo tecnico |
| Norme o specifiche applicate modificate | Cambiano i metadati di conformità | Rivedere metadati ed evidenze collegate |
Revisioni periodiche. Il CRA non fissa un intervallo di revisione prestabilito. Queste cadenze sono una base pratica:
| Cadenza | Ambito |
|---|---|
| Trimestrale | SBOM e stato delle vulnerabilità |
| Annuale | Revisione completa del fascicolo tecnico |
| Prima della fine del periodo di assistenza | Congelamento finale della documentazione |
Ogni build dovrebbe produrre un artefatto SBOM aggiornato, così l'evidenza resta al passo con ciò che consegni. Consulta gli errori comuni negli SBOM per capire cosa va storto quando i team rinunciano all'automazione.
Per quanto tempo conservare l'evidenza SBOM
Conserva lo SBOM con la documentazione tecnica per almeno 10 anni dopo l'immissione sul mercato del prodotto con elementi digitali, o per il periodo di assistenza se più lungo. La stessa regola di conservazione si applica alla documentazione tecnica e alla dichiarazione UE di conformità. Si tratta di conservare la documentazione. È cosa distinta dall'obbligo di mantenere disponibili gli aggiornamenti di sicurezza stessi, che corre per i propri dieci anni a partire da quando ciascun aggiornamento viene rilasciato.
Per una linea di prodotti venduta nel tempo, conserva l'evidenza per le versioni e gli esemplari immessi sul mercato. Non trattare la prima data di lancio come fine pratica dell'obbligo di evidenza mentre unità o versioni successive continuano a essere fornite.
| Evento | Data esemplificativa |
|---|---|
| Prima immissione del prodotto sul mercato | Marzo 2027 |
| Ultimo esemplare immesso sul mercato | Dicembre 2030 |
| Copertura pratica dell'evidenza | Fino a dicembre 2040 o oltre se il periodo di assistenza lo richiede |
Il conteggio decorre dall'ultimo esemplare immesso sul mercato, quindi dicembre 2030 più dieci anni arriva almeno a dicembre 2040, più a lungo se il periodo di assistenza si estende oltre. Conserva lo SBOM in uno spazio sicuro e con backup, con protezione dell'integrità, così da poter recuperare e fornire la versione giusta in caso di richiesta motivata.
Date e applicazione
L'applicazione integrale del CRA inizia l'11 dicembre 2027. L'obbligo di segnalazione delle vulnerabilità inizia prima, l'11 settembre 2026. Questa data anticipata non è una scadenza separata per il deposito dello SBOM, ma richiede di capire rapidamente quali versioni di prodotto e componenti sono interessati da una vulnerabilità o da un incidente da segnalare. Per i prodotti immessi sul mercato UE dopo l'applicazione integrale, lo SBOM fa parte della base probatoria dietro la valutazione della conformità, la dichiarazione UE di conformità e la marcatura CE. Per il flusso di segnalazione, consulta segnalazione di vulnerabilità e incidenti CRA. Per la cronologia generale del CRA, consulta cos'è il CRA; per la tabella delle sanzioni, consulta sanzioni e applicazione del CRA.
Domande frequenti
Il CRA richiede uno SBOM leggibile da macchina o è accettabile un PDF?
Lo SBOM deve essere in un formato di uso comune e leggibile da macchina. Un PDF o foglio di calcolo può accompagnare il file per la revisione umana, ma non sostituisce lo SBOM. CycloneDX o SPDX serializzato in JSON o XML è il percorso pratico.
Il CRA richiede uno SBOM per i componenti open source?
Sì. I componenti open source restano componenti contenuti nel prodotto, perciò vanno inseriti nello SBOM con versione e informazioni identificative. Il CRA si aspetta inoltre che tu eserciti la dovuta diligenza sui componenti di terzi che integri, compreso il software open source che non ti è stato fornito a titolo commerciale, e che segnali qualsiasi vulnerabilità individuata in un componente integrato, anche open source, a chi ne cura la fabbricazione o la manutenzione.
Quando deve essere trasmesso lo SBOM: all'immissione sul mercato o su richiesta?
Lo SBOM normalmente non viene trasmesso in modo proattivo. Deve far parte della documentazione tecnica, essere pronto e disponibile per le autorità di vigilanza del mercato in caso di richiesta motivata, ed esistere quando il prodotto è immesso sul mercato UE.
Quali sono gli elementi minimi NTIA e soddisfano i requisiti del CRA?
Gli elementi minimi NTIA (nome del fornitore, nome del componente, versione, identificatori univoci, relazioni di dipendenza, autore dello SBOM e marca temporale) sono un punto di partenza ragionevole. Da soli non rispondono a ogni esigenza di evidenza del CRA né a ogni aspettativa di qualità TR-03183. Per il lavoro CRA, valida il file generato rispetto al formato scelto, registra lo stato delle vulnerabilità e compila campi più ricchi come PURL/CPE, hash e dati di relazione quando il tuo framework di qualità li richiede.
È possibile riutilizzare gli SBOM dei fornitori per soddisfare il CRA?
In parte. Gli SBOM dei fornitori sono input validi per le parti che forniscono, ma devi comunque un unico SBOM per il prodotto così come immesso sul mercato. Ciò significa consolidare gli SBOM dei fornitori con i tuoi componenti propri e le dipendenze di build in un'evidenza a livello di prodotto, come illustrato sopra in quanti SBOM servono per un prodotto. Tratta gli SBOM dei fornitori come materia prima, non come artefatto di conformità finito.