SBOM e HBOM: cosa chiede davvero il Cyber Resilience Act
Produci, importi o vendi dispositivi connessi? Con il Cyber Resilience Act (CRA) devi sapere di quali componenti software è fatto il tuo prodotto, e dimostrarlo con una SBOM. L’HBOM, la distinta dei componenti hardware, il regolamento invece non la cita. Per chi fa hardware è però quasi sempre il modo più rapido di rispondere quando esce una vulnerabilità.
In questa guida vediamo cosa dice la norma, dove finisce l’obbligo e cosa facciamo nella pratica con i produttori che seguiamo.
Le differenze in breve
Prima di entrare nel dettaglio, ecco il confronto che ci chiedono più spesso i produttori.
| SBOM (Software Bill of Materials) | HBOM (Hardware Bill of Materials) | |
|---|---|---|
| Cosa elenca | Librerie, moduli, dipendenze e versioni di software e firmware | Componenti fisici: processori, moduli radio, chip, schede, con varianti e revisioni |
| Obbligatoria con il CRA? | Sì (Allegato I, parte II, punto 1) | No, il regolamento non la menziona |
| Formato | Di uso comune e leggibile da una macchina: SPDX o CycloneDX | Libero; CycloneDX la supporta e la CISA ha pubblicato un framework di riferimento |
| Chi la produce | Sviluppo, meglio se generata in automatico a ogni build | Ingegneria e produzione, collegata alla distinta base di produzione |
| Quando si aggiorna | A ogni rilascio software o firmware | A ogni cambio di componente, fornitore o revisione di scheda |
| A cosa serve per il CRA | Gestione delle vulnerabilità, documentazione tecnica, segnalazioni | Capire quali unità sul campo sono colpite e se una patch è applicabile |
Confronto tra SBOM e HBOM rispetto agli obblighi del Regolamento UE 2024/2847.
Cosa chiede il Cyber Resilience Act ai produttori
Il CRA (Regolamento UE 2024/2847) si applica ai prodotti con elementi digitali immessi sul mercato europeo: software, dispositivi connessi, sistemi embedded, hardware che comunica in rete o in locale.[EUR-Lex] Gli obblighi ricadono su chi fabbrica, importa o distribuisce il prodotto, non su chi lo usa. La responsabilità principale è del fabbricante, che appone la marcatura CE sulla base di una conformità dimostrabile.
Le categorie di prodotto
Non tutti i prodotti sono trattati allo stesso modo: la categoria determina la procedura di valutazione della conformità.
- Prodotti ordinarila maggioranza. Il fabbricante effettua un’autovalutazione.
- Importanti di classe I(Allegato III) autovalutazione solo se si applicano le norme armonizzate, altrimenti serve un organismo terzo.
- Importanti di classe II(Allegato III) valutazione da parte di un organismo terzo.
- Critici(Allegato IV) certificazione europea di cybersecurity dove prevista.
Le scadenze chiave
- 10 dicembre 2024entrata in vigore del regolamento.
- 11 giugno 2026norme sugli organismi di valutazione della conformità.
- 11 settembre 2026obblighi di segnalazione, già in vigore, anche per i prodotti già sul mercato.
- 11 dicembre 2027applicazione piena di tutti i requisiti.[Commissione UE]
Le segnalazioni: tre tempi, non uno
Per le vulnerabilità attivamente sfruttate e gli incidenti gravi, il fabbricante deve inviare tre comunicazioni.
| Fase | Scadenza | Cosa contiene |
|---|---|---|
| Allerta precoce | Entro 24 ore dalla conoscenza | Prima segnalazione della vulnerabilità sfruttata o dell’incidente grave. |
| Notifica | Entro 72 ore dalla conoscenza | Informazioni generali sul prodotto, sulla natura dello sfruttamento o dell’incidente e sulle misure correttive o di mitigazione. |
| Rapporto finale | 14 giorni dalla correzione (vulnerabilità) o 1 mese dalla notifica (incidenti) | Descrizione dettagliata, gravità, impatto, causa e misure adottate.[Commissione UE – Reporting] |
Processo di segnalazione previsto dall’art. 14 del Cyber Resilience Act.
La segnalazione si invia una sola volta attraverso la Single Reporting Platform di ENISA, attiva dall’11 settembre 2026.[ENISA]
Le sanzioni
| Tipo di violazione | Sanzione massima |
|---|---|
| Requisiti essenziali di cybersecurity (Allegato I) e obblighi del fabbricante | Fino a 15 milioni di euro o 2,5% del fatturato mondiale annuo |
| Altri obblighi (documentazione, marcatura CE, ecc.) | Fino a 10 milioni di euro o 2% del fatturato mondiale annuo |
| Informazioni inesatte, incomplete o fuorvianti alle autorità | Fino a 5 milioni di euro o 1% del fatturato mondiale annuo |
Sanzioni dell’art. 64 del Regolamento UE 2024/2847: si applica l’importo più alto tra valore fisso e percentuale sul fatturato.
SBOM: cos’è e cosa chiede esattamente il CRA
La SBOM (Software Bill of Materials, in italiano distinta base del software) è l’elenco strutturato dei componenti con le relative versioni. Funziona come l’etichetta degli ingredienti: non ti dice se il prodotto è sicuro, ma ti dice cosa c’è dentro. L’Allegato I chiede al fabbricante di identificare e documentare vulnerabilità e componenti del prodotto, anche redigendo una SBOM in un formato di uso comune e leggibile da una macchina che copra almeno le dipendenze di primo livello.[EUR-Lex] In pratica:
- Formato: il testo non impone uno standard, ma quelli riconosciuti sono SPDX (ISO/IEC 5962) e CycloneDX. Un PDF o un foglio Excel non è leggibile da una macchina nel senso richiesto.
- Profondità: il minimo sono le dipendenze dirette. Per gestire davvero le vulnerabilità conviene arrivare alle transitive, dove si nascondono molte librerie vulnerabili.
- Pubblicità: la SBOM fa parte della documentazione tecnica e va fornita alle autorità di vigilanza su richiesta. Non sei obbligato a pubblicarla.
- Firmware incluso: per un dispositivo riguarda anche il firmware, compreso quello dei moduli acquistati da fornitori.
Perché la SBOM ti salva le prime 24 ore
Il valore della SBOM si vede quando esce una vulnerabilità. Con una SBOM aggiornata basta una ricerca per sapere quali prodotti, versioni e clienti contengono la libreria colpita. Senza, si passa giorni a chiedere ai fornitori e ad analizzare firmware, mentre il tempo per l’allerta a 24 ore è già scaduto. La SBOM lavora insieme ai test. Quando un vulnerability assessment o un penetration test trova una libreria vulnerabile, la SBOM collega l’evidenza al componente e permette di dimostrare dove la correzione è stata applicata: è lo stesso ciclo continuo che applichiamo nel vulnerability e patch management.
HBOM: non obbligatoria, ma decisiva per chi fa hardware
L’HBOM è la distinta dei componenti fisici di un dispositivo. Il CRA non la richiede, e va detto chiaramente: chi la presenta come un obbligo sbaglia. Il regolamento chiede però di gestire le vulnerabilità per tutto il ciclo di vita del prodotto e di dimostrare che una correzione è applicabile. In un dispositivo connesso questo dipende spesso dall’hardware:
- una vulnerabilità nello stack Bluetooth riguarda solo le unità con un certo modulo radio
- un aggiornamento firmware può non essere compatibile con una vecchia revisione di scheda
- un fornitore che cambia chip a metà produzione crea due prodotti diversi con lo stesso codice articolo
Senza HBOM non sai quali unità sul campo sono colpite, e la notifica a 72 ore diventa una stima.
Da dove partire con l’HBOM
Per non inventare uno schema da zero c’è il framework HBOM della CISA, che definisce campi e livelli di dettaglio.[CISA] CycloneDX, lo stesso formato usato per la SBOM, supporta anche i componenti hardware: SBOM e HBOM possono così stare in un’unica fonte collegata. Un’HBOM utile al CRA parte dai componenti che toccano connettività e sicurezza: moduli di rete (Wi-Fi, Bluetooth, radio), processori e microcontrollori, memorie ed elementi di sicurezza, con fornitore, revisione e lotto.
SBOM
cosa gira nel prodotto: codice, librerie, firmware e versioni. Obbligatoria, generata a ogni build.
HBOM
su cosa gira: moduli, chip, schede, revisioni e lotti. Facoltativa, ma indispensabile per sapere quali unità aggiornare.
Un esempio: un modem radio per il ferroviario
Prendiamo un esempio tipico: una PMI italiana che produce apparati di telecomunicazione per il settore ferroviario, con un modem radio per la comunicazione treno-terra progettato qualche anno fa, quando di SBOM non parlava nessuno. È una situazione di partenza comune a molte PMI manifatturiere:
- La richiesta arriva da un cliente. Un partner industriale invia un questionario costruito sull’Allegato I del CRA: sempre più spesso la conformità la chiede la filiera, prima ancora delle autorità.
- Nessuna competenza cyber interna. L’azienda conosce bene le certificazioni di settore (EN 50155, EMC, safety) ma non ha personale IT dedicato.
- Più varianti dello stesso prodotto. Il modem esiste in più versioni che, ai fini della cybersecurity, potrebbero essere trattate come un unico prodotto. La SBOM però deve dire quali componenti sono comuni e quali cambiano: qui l’HBOM diventa indispensabile, anche se nessuno la chiede.
- Firmware di terzi. Parte del software arriva con il modulo radio del fornitore. Senza una SBOM richiesta al fornitore, quel pezzo resta una scatola chiusa.
In un caso così il primo obiettivo non è la conformità completa, ma una procedura di gestione delle vulnerabilità pronta subito, con la piena conformità pianificata entro dicembre 2027. È l’ordine giusto: gli obblighi di segnalazione arrivano 15 mesi prima di tutti gli altri.
Da dove partire: 5 passi per una PMI
- Inventario e ruolo: elenca i prodotti con elementi digitali che hai sul mercato e chiarisci se per ciascuno sei fabbricante, importatore o distributore.
- Classificazione: per ogni prodotto verifica se è ordinario, importante o critico, perché da qui dipende la procedura di conformità.
- Prima SBOM del prodotto principale: generala automaticamente in fase di build, in formato SPDX o CycloneDX, e chiedi le SBOM del firmware ai fornitori.
- HBOM dove l’hardware conta: parti dai componenti che toccano connettività e sicurezza e collegala alle revisioni di produzione.
- Procedura di segnalazione: decidi chi riceve le segnalazioni, chi valuta se una vulnerabilità è attivamente sfruttata e chi invia allerta e notifica. Poi mettila alla prova con una simulazione.
Lo schema è simile a quello della nostra guida al NIS2 gap assessment per PMI: si parte da cosa hai, non da cosa dovresti avere. Per il quadro generale sul regolamento trovi anche la nostra guida Cyber Resilience Act: cosa fare e da dove partire.
Domande frequenti su SBOM, HBOM e CRA
Cos’è una SBOM?
È la distinta base del software: l’elenco leggibile da una macchina di tutti i componenti software di un prodotto (librerie, moduli, dipendenze, firmware) con fornitore e versione.
La SBOM è obbligatoria per il Cyber Resilience Act?
Sì. L’Allegato I del CRA chiede al fabbricante di redigere una SBOM in un formato di uso comune e leggibile da una macchina, che copra almeno le dipendenze di primo livello. Va conservata nella documentazione tecnica, non pubblicata.
L’HBOM è obbligatoria?
No, il CRA non la menziona. Per chi produce dispositivi è però lo strumento che permette di capire quali unità sul campo sono colpite da una vulnerabilità e se una correzione è applicabile.
Qual è la differenza tra SBOM e HBOM?
La SBOM descrive cosa gira nel prodotto (software e firmware), l’HBOM su cosa gira (moduli, chip, schede e revisioni). La prima è un obbligo, la seconda una buona pratica che la rende utilizzabile sui dispositivi.
Entro quando serve la SBOM?
I requisiti dell’Allegato I si applicano dall’11 dicembre 2027. Gli obblighi di segnalazione sono però in vigore dall’11 settembre 2026, e senza una SBOM rispettare l’allerta a 24 ore è molto difficile: conviene prepararla adesso.
Che formato deve avere la SBOM?
Il regolamento non impone uno standard. I formati più usati e riconosciuti sono SPDX (ISO/IEC 5962) e CycloneDX, entrambi generabili in automatico dagli strumenti di build.
Come ti aiutiamo a prepararti al CRA
Il nostro percorso sul Cyber Resilience Act parte da una verifica di applicabilità e classificazione e porta a una roadmap concreta. Per i prodotti già sul mercato la prima fase è preparare la procedura di segnalazione, perché è l’obbligo già in vigore. Mettiamo insieme consulenza e test tecnici, cioè vulnerability assessment e penetration test, e produciamo documentazione utilizzabile in caso di audit e sorveglianza di mercato. La marcatura CE resta al fabbricante: noi ti portiamo pronto a farla.
Fonti
- [EUR-Lex] Regolamento (UE) 2024/2847 – Cyber Resilience Act
- [Commissione UE] Cyber Resilience Act – sintesi e scadenze
- [Commissione UE – Reporting] Cyber Resilience Act – obblighi di segnalazione
- [ENISA] The CRA Single Reporting Platform is launched
- [CISA] Hardware Bill of Materials (HBOM) Framework
Questo articolo ha finalità informative e non costituisce consulenza legale. L’applicabilità del Cyber Resilience Act e la classificazione del prodotto vanno valutate caso per caso.
