Hardware Bill of Materials (HBOM) e conformità al CRA

La tua SBOM elenca librerie e pacchetti software, ma che cosa succede al firmware caricato nel chip Bluetooth o al microcontrollore al centro del dispositivo? Una distinta base hardware (HBOM) estende l'inventario dei componenti a chip fisici, moduli e firmware che vi gira sopra. Il CRA non usa il termine «HBOM», ma prodotti hardware, componenti hardware immessi separatamente sul mercato, due diligence sui componenti di terzi e inventario SBOM portano allo stesso bisogno pratico: sapere quali hardware e firmware sono dentro il prodotto.

Perché l’HBOM rileva ai sensi del CRA

L'ambito del CRA è più ampio dei soli prodotti software. Prodotti hardware, componenti hardware commercializzati separatamente e firmware dentro quei componenti rientrano tutti nel problema dell'inventario del prodotto.

Questo conta per i fabbricanti perché la due diligence sui componenti non si limita alle librerie open source. Un processore sulla PCB, un modulo wireless sulla scheda di sviluppo o un secure element nel gateway IoT possono avere firmware e versioni rilevanti per la sicurezza. Non puoi gestire questi rischi senza inventariarli.

L'obbligo SBOM è la sede giuridica di questo lavoro: richiede i componenti contenuti nei prodotti con elementi digitali. Un modulo ESP32 porta quindi nel registro dei componenti sia il modulo fisico sia il suo stack firmware. La HBOM è lo strumento pratico per catturare questo inventario.

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
Ruolo di conformità	Requisito esplicito di inventario componenti	Estensione pratica dello stesso inventario per prodotti hardware
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	Fascicolo tecnico, sezione inventario componenti	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 ingegneristico pratico, non un elenco normativo. Il CRA non enumera categorie di componenti hardware. Includi qualsiasi componente fisico che elabori, memorizzi o trasmetta dati digitali, perché questi componenti possono incidere sulla cibersicurezza.

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.

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. Per il lavoro CRA, trattalo come software perché è codice informatico che gira dentro un sistema informativo elettronico.

L'implicazione pratica è semplice. Il firmware che gira su un chip del tuo prodotto è un componente software del prodotto con elementi digitali. Deve apparire nell'inventario dei componenti. Se contiene una vulnerabilità, quella vulnerabilità segue lo stesso flusso di gestione e notifica di qualsiasi altra 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	Baseline target per il 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 o successivo 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.