L'applicazione integrale del CRA inizia l'11 dicembre 2027. Da tale data, ogni prodotto con elementi digitali immesso sul mercato UE deve recare la marcatura CE, e la marcatura CE richiede uno SBOM conforme. L'Allegato I, Parte II, punto 1 è la clausola operativa: i fabbricanti devono «identificare e documentare le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto». Tale formulazione determina il formato, l'ambito e il punto del fascicolo tecnico in cui lo SBOM deve essere collocato. Questa pagina illustra esattamente ciò che la legge richiede e ciò che non richiede.
Riepilogo
- Gli SBOM sono obbligatori ai sensi dell'Allegato I, Parte II, punto 1 per ogni prodotto con elementi digitali
- Il formato deve essere leggibile da un dispositivo automatico (CycloneDX o SPDX; i PDF e i fogli di calcolo non sono ammessi)
- Copertura minima: dipendenze di primo livello del prodotto; la copertura delle dipendenze transitive è una buona pratica ma va oltre il minimo normativo
- Lo SBOM fa parte della documentazione tecnica dell'Allegato VII (punto 2(b), con il punto 8 relativo alle copie da fornire su richiesta alle autorità di vigilanza del mercato)
- L'obbligo è continuativo: i trigger di aggiornamento includono ogni rilascio firmware, ogni modifica di componente e ogni scoperta di vulnerabilità
- Applicazione integrale: 11 dicembre 2027; l'obbligo di segnalazione delle vulnerabilità decorre dall'11 settembre 2026
Gli obblighi SBOM del CRA
Il CRA fa riferimento agli SBOM in due sezioni fondamentali.
Allegato I: requisiti essenziali
Il testo ufficiale dell'Allegato I, Parte II, punto 1 recita:
«identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto»
Ciò significa:
- Gli SBOM sono obbligatori, non facoltativi
- Devono essere in formato leggibile da un dispositivo automatico (non PDF o fogli di calcolo)
- Devono coprire almeno le dipendenze di primo livello del prodotto; la copertura delle dipendenze transitive è una buona pratica ma va oltre il minimo normativo
Ogni prodotto con elementi digitali immesso sul mercato UE deve disporre di uno SBOM leggibile da un dispositivo automatico. Non esiste alcuna deroga né alcuna soglia dimensionale al di sotto della quale l'obbligo venga meno.
Allegato VII: documentazione tecnica
Il fascicolo tecnico dell'Allegato VII menziona lo SBOM in due punti:
- Punto 2(b): la descrizione dei processi di gestione delle vulnerabilità «tra cui la distinta base del software» deve far parte della documentazione tecnica conservata dal fabbricante.
- Punto 8: «se del caso, la distinta base del software» deve essere fornita «a seguito di una richiesta motivata di un'autorità di vigilanza del mercato».
Lo SBOM non viene trasmesso in modo proattivo. Deve esistere al momento dell'immissione del prodotto sul mercato UE ed essere pronto per le autorità su richiesta.
Lo SBOM nell'Allegato VII deve consentire:
- Il tracciamento delle vulnerabilità a livello di componente
- L'identificazione dei fornitori
- La verifica della conformità delle licenze
- La pianificazione della fine vita
Contenuto dello SBOM dell'Allegato VII
La documentazione tecnica richiede tre dimensioni per lo SBOM: formato, contenuto e ambito. La tabella seguente riflette quanto verificheranno le autorità di vigilanza del mercato.
| Categoria | Requisito | Fonte |
|---|---|---|
| Formato | Leggibile da un dispositivo automatico (CycloneDX o SPDX) | Allegato I, Parte II, punto 1 |
| Formato | Riepilogo leggibile dall'operatore umano | Buona pratica |
| Contenuto | Tutti i componenti software elencati | Allegato I |
| Contenuto | Versioni dei componenti specificate | Allegato I |
| Contenuto | Informazioni sul fornitore | Allegato I; TR-03183 |
| Contenuto | Informazioni sulle licenze | TR-03183 |
| Contenuto | Vulnerabilità note al momento della valutazione | Allegato VII, punto 2(b) |
| Ambito | Dipendenze dirette (di primo livello) | Allegato I (minimo normativo) |
| Ambito | Dipendenze transitive | TR-03183 (buona pratica) |
| Ambito | Componenti del sistema operativo, ove applicabile | TR-03183 |
| Ambito | Librerie di terze parti | Allegato I |
Per i requisiti specifici sui campi che vanno oltre questa checklist (identificatori PURL, valori hash, metadati del documento), si consulti come BSI TR-03183 estende il CRA. Per un confronto tra gli strumenti CycloneDX e SPDX, si consulti CycloneDX vs SPDX.
Esempio di voce SBOM conforme
Una voce correttamente strutturata nel fascicolo tecnico dell'Allegato VII fa riferimento al file leggibile automaticamente e registra lo stato delle vulnerabilità al momento della valutazione:
SOFTWARE BILL OF MATERIALS
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.5
Generated: 2027-01-15
Tool: Trivy + syft
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached)
COMPONENT SUMMARY:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
VULNERABILITY STATUS AT ASSESSMENT:
-------------------------------------------------------------
Scan Date: 2027-01-15
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
ACCEPTED VULNERABILITIES:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
SBOM UPDATE COMMITMENT:
SBOM will be updated with each firmware release and made
available to customers upon request.
Quando aggiornare lo SBOM
Lo SBOM non è un documento una tantum. Il fascicolo tecnico deve essere aggiornato per tutta la durata del ciclo di vita del prodotto.
Trigger di aggiornamento obbligatori:
| Trigger | Cosa cambia | Aggiornamento SBOM richiesto? |
|---|---|---|
| Nuova versione firmware o software | Nuovo artefatto di build | Sì, rigenerazione completa |
| Rilascio di patch di sicurezza | Versione del componente aggiornata | Sì, componenti interessati |
| Vulnerabilità scoperta e risolta | Stato VEX o di sfruttabilità | Sì, campi VEX |
| Componente aggiunto, rimosso o sostituito | Grafico delle dipendenze | Sì, rigenerazione completa |
| Modifica progettuale con impatto sulla sicurezza | Componenti e architettura | Sì, rigenerazione completa |
| Modifica degli standard armonizzati applicati | Riferimento agli standard | Sì, metadati |
Revisioni periodiche:
| 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 |
La creazione manuale degli SBOM è soggetta a errori e non è scalabile tra le versioni del prodotto. Ogni build dovrebbe produrre un artefatto SBOM aggiornato. Si consulti gli errori comuni negli SBOM per capire cosa accade quando i team rinunciano all'automazione.
Obblighi di conservazione
L'Articolo 13, paragrafo 13 impone ai fabbricanti di tenere la documentazione tecnica e la dichiarazione di conformità UE a disposizione delle autorità di vigilanza del mercato «per un periodo di almeno dieci anni dalla data di immissione sul mercato del prodotto con elementi digitali o per il periodo di assistenza, se quest'ultimo è superiore». Il computo parte dall'ultimo esemplare immesso sul mercato, non dal primo.
| Evento | Data esemplificativa |
|---|---|
| Prima immissione del prodotto sul mercato | Marzo 2027 |
| Immissione dell'ultimo esemplare sul mercato | Dicembre 2030 |
| Conservazione della documentazione fino a (minimo 10 anni) | Dicembre 2040 |
Lo SBOM deve essere conservato in uno spazio di archiviazione sicuro e accessibile, con procedure di backup, protezione dell'integrità e capacità di recuperarlo e fornirlo a seguito di una richiesta motivata di un'autorità di vigilanza del mercato. Il punto 8 dell'Allegato VII specifica che lo SBOM viene fornito «a seguito di una richiesta motivata» e non in modo proattivo.
Applicazione e sanzioni
L'applicazione integrale del CRA inizia l'11 dicembre 2027. L'obbligo di segnalazione delle vulnerabilità ai sensi dell'Articolo 14 decorre prima, dall'11 settembre 2026. I prodotti immessi sul mercato UE dopo il dicembre 2027 privi di uno SBOM conforme non possono recare la marcatura CE e non possono essere legalmente commercializzati nell'UE. Per la cronologia completa e il dettaglio delle sanzioni, si consulti scadenze e sanzioni SBOM del CRA.
Domande frequenti
Il CRA richiede uno SBOM leggibile da un dispositivo automatico o è accettabile un PDF?
L'Allegato I richiede esplicitamente il formato leggibile da un dispositivo automatico. Un PDF non è accettabile. CycloneDX o SPDX serializzati in JSON o XML soddisfano il requisito. Un foglio di calcolo o un documento leggibile solo dall'operatore umano non lo soddisfano.
Il CRA richiede uno SBOM per i componenti open source?
Sì. L'Allegato I stabilisce che i fabbricanti devono documentare i componenti in uno SBOM leggibile da un dispositivo automatico, senza eccezioni per l'open source. Se una libreria open source è presente nel prodotto, deve figurare nello SBOM con le informazioni sulla versione e sull'identificatore.
Quando deve essere trasmesso lo SBOM: al momento dell'immissione sul mercato o su richiesta?
Lo SBOM non deve essere trasmesso in modo proattivo. Deve far parte del fascicolo tecnico (Allegato VII), pronto e disponibile per le autorità di vigilanza del mercato su richiesta. Deve esistere al momento dell'immissione del prodotto 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 in linea generale allineati a quanto richiesto dal CRA e da BSI TR-03183 al livello base. Rappresentano un punto di partenza ragionevole, ma i campi obbligatori di TR-03183 vanno oltre: i valori hash e gli identificatori PURL sono attesi per la conformità al CRA.
È possibile riutilizzare gli SBOM dei propri fornitori per soddisfare il CRA?
In parte. Gli SBOM dei fornitori sono un input valido per i componenti da loro forniti, e il CRA si aspetta che i fabbricanti si avvalgano della documentazione upstream. L'obbligo previsto dall'Allegato I grava tuttavia sul fabbricante del prodotto integrato: è necessario produrre e mantenere uno SBOM per il prodotto come consegnato, il che comporta il consolidamento degli SBOM dei fornitori con i propri componenti di prima parte e le dipendenze di build. Se uno SBOM del fornitore è privo dei campi richiesti da BSI TR-03183 (PURL, hash, licenza), il fabbricante è responsabile di colmare tali lacune. Gli SBOM dei fornitori vanno trattati come materia prima, non come artefatto di conformità già pronto.