Il suo SBOM elenca librerie e pacchetti software, ma cosa ne è del firmware integrato nel chip Bluetooth o del microcontrollore al cuore del dispositivo? Un Hardware Bill of Materials (HBOM) estende l’inventario dei componenti per includere chip fisici, moduli e il firmware in esecuzione su di essi. Il CRA definisce «prodotto con elementi digitali» all’Articolo 3(1) in modo da includere i prodotti hardware, e definisce «hardware» all’Articolo 3(5) come «un sistema di informazione elettronico fisico, o parti di esso, in grado di trattare, conservare o trasmettere dati digitali». Il regolamento non utilizza il termine «HBOM» in nessun punto, ma l’obbligo di documentare e esercitare la dovuta diligenza su tutti i componenti, inclusi quelli hardware, discende direttamente dall’Articolo 3(1), dall’Articolo 13(5) e dall’Allegato I, Parte II, punto (1).
Riepilogo
- Un HBOM è un inventario strutturato dei componenti fisici del prodotto, compreso il firmware presente in ciascun componente
- Il CRA non impone un HBOM con questo nome, ma l’Articolo 3(1) estende l’ambito del CRA ai prodotti hardware, l’Articolo 13(5) richiede la dovuta diligenza su tutti i componenti di terze parti, e l’Allegato I, Parte II, punto (1) impone di documentare i «componenti contenuti nei prodotti con elementi digitali»
- Il firmware è software ai sensi dell’Articolo 3(4): «è composto da codice informatico» e deve comparire nello SBOM accanto alle voci dei componenti hardware
- CycloneDX è il formato unificato pratico:
type: devicecopre l’hardware fisico,type: firmwarecopre il software integrato, ed entrambi possono coesistere in un unico documento CycloneDX 1.6 - BSI TR-03183 non copre attualmente il concetto di HBOM; tutte e tre le parti si concentrano sulle distinte base del software e sui rapporti sulle vulnerabilità
- La Commissione potrà specificare il formato e gli elementi degli SBOM tramite atti di esecuzione (Articolo 13(24)), ma nel testo del CRA non esiste un mandato parallelo per un formato HBOM distinto
Perché l’HBOM rileva ai sensi del CRA
L’ambito del CRA è più ampio di quello dei «prodotti software». L’Articolo 3(1) definisce «prodotto con elementi digitali» come:
«qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati da remoto, compresi i componenti software o hardware immesso sul mercato separatamente»
L’Articolo 3(5) definisce «hardware» come:
«un sistema di informazione elettronico fisico, o parti di esso, in grado di trattare, conservare o trasmettere dati digitali»
Tale definizione copre il processore sul PCB, il modulo wireless sulla scheda di sviluppo e il secure element nel gateway IoT. Questi non sono elementi secondari rispetto alla conformità al CRA: rientrano pienamente nel suo ambito.
L’Articolo 13(5) pone poi un obbligo concreto in capo al fabbricante:
«Ai fini dell'adempimento dell'obbligo di cui al paragrafo 1, i fabbricanti esercitano la dovuta diligenza quando integrano componenti provenienti da terzi affinché tali componenti non compromettano la cibersicurezza del prodotto con elementi digitali, anche quando integrano componenti di software liberi e open source che non sono stati messi a disposizione sul mercato nel corso di un'attività commerciale.»
Non è possibile esercitare la dovuta diligenza sui componenti hardware che non si sono preventivamente inventariati. L’Allegato I, Parte II, punto (1) estende ulteriormente questo obbligo: lo SBOM deve coprire «vulnerabilità e componenti contenuti nei prodotti con elementi digitali». Un prodotto che contiene un modulo ESP32 contiene lo stack firmware di quel modulo come componente. L’HBOM è lo strumento pratico per catturare tale inventario.
Il CRA non contiene alcuna disposizione che richieda un documento denominato HBOM. L’obbligo è di inventariare tutti i componenti, inclusi quelli hardware, nell’obbligo SBOM esistente previsto dall’Allegato I, Parte II, punto (1). L’HBOM è un approccio pratico per adempiere a tale obbligo nei prodotti ad alta componente hardware, non un documento di conformità separato.
HBOM e SBOM a confronto
| Dimensione | SBOM | HBOM |
|---|---|---|
| Ambito principale | Librerie software, pacchetti, framework | Componenti fisici: chip, moduli, secure element |
| Copertura firmware | Può includere voci type: firmware |
Firmware elencato accanto al componente hardware di riferimento |
| Mandato CRA | Esplicito, Allegato I, Parte II, punto (1) | Implicito, tramite l’ambito dell’Articolo 3(1) e la dovuta diligenza dell’Articolo 13(5) |
| Copertura BSI TR-03183 | Sì, TR-03183-2 (v2.1.0, 2025) | No, nessuna delle tre parti di TR-03183 copre l’HBOM |
| Supporto CycloneDX | Tutte le versioni | type: device dalla v1.1; type: firmware dalla v1.2 (maggio 2020) |
| Strumento di generazione tipico | Syft, Trivy, cdxgen | Manuale o schede tecniche dei fornitori hardware; nessuno strumento maturo di generazione automatica |
| Posizione nel fascicolo tecnico | Allegato VII, punto 2(b) e punto 8 | Stessa posizione, come parte dell’inventario unificato dei componenti |
Per l’obbligo SBOM completo, si consulti Requisiti SBOM del CRA. Per il confronto tra formati, si consulti CycloneDX vs SPDX.
Cosa includere in un HBOM
Le categorie seguenti riflettono il giudizio tecnico pratico, non un elenco normativo. Il CRA non enumera le categorie di componenti hardware. Si dovrebbe includere qualsiasi componente fisico che elabora, memorizza o trasmette dati digitali, in quanto è quanto copre l’Articolo 3(5).
Componenti di elaborazione e connettività
Queste sono le voci ad alta priorità perché il loro firmware è il vettore più probabile di vulnerabilità:
- Processore applicativo principale o SoC (nome, produttore, versione/stepping, versione firmware)
- Moduli wireless: Wi-Fi, Bluetooth, Zigbee, LoRa, cellulare (ciascuno con versione firmware)
- Microcontrollori secondari che gestiscono sottosistemi specifici
Componenti di sicurezza
L’hardware di sicurezza merita voci proprie perché le vulnerabilità in questo ambito hanno l’impatto più elevato:
- Chip Trusted Platform Module (TPM)
- Secure element e moduli di sicurezza hardware
- Acceleratori crittografici
- Qualsiasi componente che memorizza chiavi, certificati o credenziali a riposo
Componenti di storage
Lo storage rileva quando contiene codice, configurazione o dati sensibili:
- Memoria flash contenente bootloader o firmware
- Moduli eMMC o SD se utilizzati per storage persistente
- EEPROM contenente configurazione del dispositivo
Per ciascuna voce, registrare come minimo: nome del componente, produttore, versione hardware o stepping, e versione firmware ove applicabile. Collegare ciascuna voce hardware alla corrispondente voce firmware tramite le relazioni di dipendenza di CycloneDX.
Una quota significativa delle vulnerabilità IoT riguarda firmware che non viene mai aggiornato dopo la spedizione. Documentare le versioni del firmware nell’HBOM è il prerequisito per il monitoraggio e la remediation. Non è possibile tracciare ciò che non si è elencato. Si veda gli errori SBOM comuni per il pattern più ampio.
Come il firmware rientra nella definizione CRA di software
Il firmware viene talvolta trattato come una categoria speciale, distinta sia dall’hardware sia dal software. Il CRA non crea questa terza categoria. L’Articolo 3(4) definisce il software come:
«la parte di un sistema di informazione elettronico costituita da un codice informatico»
Il firmware è composto da codice informatico. Ai sensi del CRA, il firmware è quindi software. Non si tratta di un’interpretazione che va oltre il testo: discende direttamente dalla definizione.
La parola «firmware» non compare in nessun punto del testo del CRA. Questo è intenzionale: la definizione dell’Articolo 3(4) è sufficientemente ampia da includerlo, rendendo superflua una classificazione separata.
L’implicazione pratica è immediata. Il firmware in esecuzione su un chip nel prodotto è un componente software del prodotto con elementi digitali. Deve comparire nell’inventario dei componenti. Se contiene una vulnerabilità, tale vulnerabilità è soggetta agli stessi obblighi di segnalazione previsti dall’Articolo 14 applicabili a qualsiasi vulnerabilità software.
CycloneDX come formato unificato per SBOM e HBOM
CycloneDX gestisce componenti hardware e software in un unico documento. Non è necessario un formato di file separato per l’HBOM.
Cronologia dei tipi di componente (rilevante per l’hardware)
| Versione CycloneDX | Data di rilascio | Aggiunta rilevante |
|---|---|---|
| 1.1 o precedente | 2018 | Introdotto type: device |
| 1.2 | 26 maggio 2020 | Aggiunto type: firmware |
| 1.5 | 26 giugno 2023 | Aggiunto type: device-driver |
| 1.6 | 2024 | Raccomandazione attuale per la conformità al CRA |
| 1.7 | Ottobre 2025 | Ultima versione stabile |
Non esiste type: hardware in nessuna versione di CycloneDX. Il tipo corretto per un chip fisico o un modulo è type: device.
Le specifiche CycloneDX v1.2 sulla modellazione di hardware con firmware indicano:
"A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device."
Questa indicazione si allinea direttamente al trattamento del CRA: il dispositivo fisico e il suo firmware sono componenti correlati ma distinti, ciascuno con identità e versione proprie.
Per i nuovi lavori HBOM, si adotti CycloneDX 1.6. BSI TR-03183-2 v2.1.0 (20 agosto 2025) ha elevato il requisito minimo CycloneDX a 1.6. Allinearsi alla versione 1.6 consente di mantenere SBOM e HBOM nello stesso documento e soddisfa TR-03183.
Esempio: dispositivo ESP32 con stack firmware
L’esempio seguente mostra un componente hardware realistico (ESP32-WROOM-32E), il suo firmware (ESP-IDF) e una libreria nel firmware (mbedtls), in un unico documento CycloneDX 1.6 con relazioni di dipendenza:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "device",
"name": "ESP32-WROOM-32E",
"version": "Rev 3",
"manufacturer": { "name": "Espressif Systems" },
"description": "WiFi+BT SoC Module",
"properties": [
{ "name": "firmware-version", "value": "4.4.1" },
{ "name": "secure-boot", "value": "supported" }
]
},
{
"type": "firmware",
"name": "ESP-IDF",
"version": "4.4.1",
"description": "Firmware on ESP32"
},
{
"type": "library",
"name": "mbedtls",
"version": "2.28.0",
"description": "TLS library in firmware"
}
],
"dependencies": [
{ "ref": "ESP32-WROOM-32E", "dependsOn": ["ESP-IDF"] },
{ "ref": "ESP-IDF", "dependsOn": ["mbedtls"] }
]
}
L’array dependencies rende esplicita la relazione tra hardware e firmware. Quando mbedtls rilascia una patch per un CVE, è possibile risalire al dispositivo interessato e alla versione firmware da aggiornare.
Per il confronto dei formati e le scelte degli strumenti, si consulti CycloneDX vs SPDX.
Domande frequenti
Il CRA richiede esplicitamente un HBOM?
No, il CRA non utilizza il termine «HBOM» in nessun punto. L’obbligo di documentare i componenti hardware deriva indirettamente: l’Articolo 3(1) porta i prodotti hardware nel perimetro del CRA, l’Articolo 13(5) richiede la dovuta diligenza su tutti i componenti di terze parti, e l’Allegato I, Parte II, punto (1) impone di documentare i «componenti contenuti nei prodotti con elementi digitali». L’HBOM è l’approccio pratico per adempiere a questi obblighi per i prodotti hardware, non un requisito normativo nominato.
Il firmware in un chip Bluetooth è considerato software ai sensi del CRA?
Sì. L’Articolo 3(4) definisce il software come «la parte di un sistema di informazione elettronico che è composta da codice informatico». Il firmware è composto da codice informatico e rientra quindi in tale definizione. La parola «firmware» non compare nel CRA: non è necessaria, perché la definizione dell’Articolo 3(4) la copre già. Qualsiasi firmware in esecuzione su un componente del prodotto è un componente software del prodotto con elementi digitali e deve comparire nell’inventario dei componenti.
BSI TR-03183 copre gli HBOM?
No. BSI TR-03183 è articolata in tre parti: Parte 1 (Requisiti generali), Parte 2 (SBOM) e Parte 3 (Rapporti sulle vulnerabilità). Nessuna di esse copre l’HBOM come concetto strutturale. TR-03183-2 menziona il firmware solo come tipo di file di componente all’interno di una distinta base del software, tramite il campo software_additionalPurpose: firmware. Per documentare i componenti hardware ai fini della conformità al CRA, è necessario ricorrere al giudizio tecnico e ai tipi hardware nativi di CycloneDX, senza poter fare affidamento sulle indicazioni TR-03183 per quella parte dell’inventario.
Quale versione di CycloneDX supporta sia i componenti software sia quelli hardware?
type: device è presente in CycloneDX dalla v1.1 (2018 o precedente). type: firmware è stato aggiunto nella v1.2, rilasciata a maggio 2020. Entrambi sono quindi disponibili in qualsiasi versione recente di CycloneDX. Per i lavori CRA, si adotti la v1.6 o successiva: BSI TR-03183-2 v2.1.0 (agosto 2025) ha elevato il requisito minimo CycloneDX a 1.6, e l’ultima versione stabile è la 1.7 (ottobre 2025). Non esiste type: hardware in nessuna versione di CycloneDX: si utilizzi type: device per i componenti fisici.