HBOM: guida Hardware Bill of Materials per il CRA

La SBOM elenca librerie e pacchetti software. Non dice se il modulo radio del prodotto è fuori supporto, se il bootloader è aggiornabile o quale lotto ha utilizzato un chipset sostituito.

Questo è il compito di un Hardware Bill of Materials (HBOM). Il CRA non usa il termine «HBOM», ma prodotti hardware, firmware, due diligence sui componenti di terze parti e inventario SBOM dei componenti puntano tutti allo stesso bisogno pratico: sapere quali hardware e firmware sono all'interno del prodotto e sapere se si può agire quando emerge una vulnerabilità.

Perché l'HBOM è rilevante ai sensi del CRA

L'ambito del CRA è più ampio dei soli prodotti software. Prodotti hardware, componenti hardware commercializzati separatamente e firmware di 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, impostazioni di sicurezza e date di supporto. Non è possibile gestire questi rischi senza inventariarli.

L'obbligo SBOM è la sede in cui questa evidenza si colloca di solito. Il CRA chiede ai fabbricanti di identificare e documentare componenti e vulnerabilità, anche tramite una SBOM leggibile da macchina che copra almeno le dipendenze di primo livello. 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 lato hardware dell'inventario.

I periodi di supporto fanno parte dello stesso quadro. Il CRA consente di tener conto dei periodi di supporto dei componenti principali. La documentazione tecnica deve quindi contenere le informazioni utilizzate per stabilire il periodo di supporto del prodotto. Se un chipset o un modulo raggiunge la fine del supporto prima del termine del periodo di supporto del prodotto, la HBOM è il luogo in cui quel fatto deve emergere per primo.

Come si presenta un HBOM nella reale catena di fornitura

Si immagini un importatore UE che acquista un gateway connesso da un ODM di Shenzhen. L'importatore non ha bisogno di ogni resistore. Ha bisogno dei dati costruttivi che modificano il rischio informatico: modulo radio, versione firmware di base, stato del supporto e sostituzioni approvate.

La differenza fondamentale è il registro as-built. Una design BOM indica ciò che il team tecnico intendeva utilizzare. La HBOM deve catturare anche ciò che la fabbrica ha effettivamente spedito.

HBOM e SBOM a confronto

Per l'obbligo SBOM completo, si consulti i requisiti SBOM del CRA. Per il confronto tra formati, si consulti CycloneDX vs SPDX.

Cosa includere e dove fermarsi

Il CRA non fornisce un elenco normativo dei campi HBOM. Non richiede nemmeno di elencare ogni componente fisico passivo. La base dell'inventario dei componenti stabilisce un livello minimo di dipendenze di primo livello per la SBOM, e il lato hardware deve seguire la stessa logica di rischio.

Soglia da applicare: elencare l'hardware che può modificare il rischio informatico del prodotto, lo stato delle vulnerabilità, il percorso di aggiornamento o le prove del periodo di supporto.

Iniziare con i componenti che svolgono uno di questi compiti:

• Elaborare dati: processori principali, SoC, microcontrollori, FPGA e ASIC correlati alla sicurezza.
• Archiviare codice o segreti: flash, eMMC, Trusted Platform Module (TPM), secure element e controller di storage.
• Trasmettere dati: moduli Wi-Fi, Bluetooth, Zigbee, Thread, LoRaWAN, NFC, Ethernet, cellulare e GNSS.
• Avviare o aggiornare il prodotto: boot manager, bootloader, UEFI, BIOS, firmware del Baseboard Management Controller (BMC) e controller di aggiornamento.
• Applicare la sicurezza: acceleratori crittografici, radici di fiducia hardware, archivi chiavi e secure enclave.
• Esporre accessi di servizio: porte di debug di produzione, JTAG, UART, SWD o interfacce di gestione in cui lo stato di blocco della produzione è rilevante.

I componenti passivi come resistori e condensatori ordinari rientrano normalmente al di fuori dell'HBOM, a meno che non abbiano una funzione di sicurezza, un'identità digitale, firmware o un rischio di sostituzione noto. Il test pratico è semplice: se una vulnerabilità, un avviso, una comunicazione EOL o una sostituzione del fornitore per quel componente modificherebbe la decisione di rischio del prodotto, includerlo.

Categorie hardware ad alta priorità

Le categorie seguenti non costituiscono un elenco normativo. Sono le voci più probabilmente rilevanti nelle prove CRA perché portano firmware, chiavi, interfacce o dipendenze di supporto dai fornitori.

Per ciascuna voce, registrare come minimo: nome del componente, fabbricante, versione hardware o stepping e versione firmware ove applicabile. Collegare ciascuna voce hardware alla corrispondente voce firmware tramite le relazioni di dipendenza di CycloneDX.

Livelli firmware che spesso si trascurano

Un singolo campo «versione firmware» è spesso troppo superficiale. Molti prodotti contengono diversi livelli firmware con proprietari, percorsi di aggiornamento e fonti di vulnerabilità differenti.

I livelli spesso trascurati includono:

• Firmware di avvio: boot ROM, bootloader, boot manager e configurazione del secure boot.
• Firmware radio: firmware Wi-Fi, Bluetooth, baseband cellulare, Zigbee, Thread, LoRaWAN e NFC.
• Firmware di piattaforma: UEFI, BIOS, BMC, option ROM e microcode CPU. NIST SP 800-193 tratta il firmware di piattaforma come hardware e firmware fondamentali necessari per avviare e far funzionare un sistema.
• Firmware di controller: controller storage, schede di rete, controller di alimentazione, hub sensori e controller integrati.
• Firmware di sicurezza: firmware TPM, sistemi operativi di secure element, applet di secure element, immagini di Trusted Execution Environment (TEE) e firmware HSM.
• Logica programmabile: bitstream FPGA e configurazione di ASIC o FPGA correlati alla sicurezza.
• Blob binari del fornitore: blob firmware forniti con l'SDK, inclusi nell'immagine del prodotto ma gestiti da un fornitore di chip o moduli.

Ciascun livello deve essere un componente separato quando ha una propria versione, un percorso di aggiornamento, un manutentore o una fonte di avvisi. Questo è ciò che consente di rispondere poi alla domanda utile: quali versioni esatte del prodotto sono interessate da questo avviso firmware?

I campi che rendono utile un HBOM

Il livello minimo normativo è più ristretto di un HBOM utile. I campi seguenti non sono tutti obbligatori ai sensi del CRA. Sono le prove che consentono di gestire vulnerabilità, cambiamenti di fornitori e decisioni sul periodo di supporto senza partire da zero.

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

L'implicazione pratica è diretta. Il firmware che gira su un chip del 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.

Se il firmware non può essere aggiornato

Alcuni firmware non possono essere aggiornati in campo. Il boot ROM può essere programmato a maschera. Il codice del secure element può essere controllato dal fornitore. Un modulo radio può non esporre alcun percorso di aggiornamento per il cliente. Questo non fa sparire il componente dalle prove CRA.

Il CRA si aspetta che le vulnerabilità siano affrontabili tramite aggiornamenti di sicurezza ove applicabile. Se un componente hardware non può ricevere aggiornamenti, documentare quel fatto nell'HBOM e nella valutazione del rischio.

Registrare:

• Stato di aggiornamento: aggiornabile in campo, solo dal fornitore, solo in fabbrica o immutabile.
• Motivo: ROM, memoria programmabile una sola volta, modulo fornitore bloccato, vincolo di certificazione o assenza di canale di aggiornamento esposto.
• Controlli compensativi: isolamento, funzionalità disabilitata, restrizione di rete, autenticazione aggiuntiva o mitigazione a livello di prodotto.
• Percorso di risposta: aggiornamento firmware, sostituzione del modulo, richiamo dell'unità, avviso ai clienti o dichiarazione VEX not_affected quando il percorso vulnerabile non è raggiungibile.
• Intervallo interessato: versione del prodotto, revisione PCB, lotto o intervallo di seriale.

Se una vulnerabilità sfruttabile non può essere corretta o mitigata, gli obblighi di azione correttiva del CRA possono imporre misure correttive, ritiro o richiamo. La HBOM deve fornire l'intervallo di prodotti interessati prima che quella decisione diventi urgente.

La fine del ciclo di vita dei componenti incide sul periodo di supporto

Il periodo di supporto del prodotto non è solo una promessa di servizio al cliente. È parte del modello di gestione delle vulnerabilità del CRA.

Il CRA consente di tener conto dei periodi di supporto dei componenti principali di terze parti integrati nella definizione del periodo di supporto del prodotto. La documentazione tecnica deve quindi contenere le informazioni utilizzate per determinare tale periodo. Gli esempi di hardware longevo nelle indicazioni del CRA includono schede madri, microprocessori, router, modem, switch e sistemi di controllo industriale, spesso utilizzati per più di cinque anni.

Questo rende la fine del ciclo di vita del componente un campo HBOM, non solo una nota di approvvigionamento.

Per i componenti principali, registrare:

• Data di fine supporto del fornitore: mese e anno, ove disponibili.
• Data dell'ultimo rilascio firmware: la data più recente in cui il fornitore ha distribuito un aggiornamento firmware rilevante per la sicurezza.
• Fonte degli avvisi: pagina PSIRT, feed CSAF, mailing list o contatto del fornitore.
• Percorso di sostituzione: componente pin-compatibile, piano di riprogettazione, decisione last-time-buy o decisione di EOL del prodotto.
• Copertura contrattuale: se gli obblighi di patch e notifica del fornitore coprono il periodo di supporto del prodotto dichiarato.

Se un modulo principale termina il supporto prima del prodotto, occorre prendere una decisione prima dell'immissione sul mercato. Estendere la copertura del fornitore, scegliere un componente diverso, limitare il periodo di supporto del prodotto ove giustificato o documentare un piano di sostituzione.

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)

Non esiste type: hardware in nessuna versione di CycloneDX. Il tipo corretto per un chip fisico o un modulo è type: device.

Le indicazioni sui tipi di componente CycloneDX trattano il dispositivo fisico e il software che vi gira come componenti separati. Un processore o un chipset deve essere rappresentato come device, mentre il codice che vi gira deve essere rappresentato come firmware o operating-system, a seconda del caso.

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, adottare CycloneDX 1.6 o successivo. BSI TR-03183-2 v2.1.0 (2025-08-20) ha elevato il requisito minimo CycloneDX a 1.6. Allinearsi alla versione 1.6 o successiva consente di mantenere SBOM e HBOM nello stesso documento e soddisfa TR-03183.

CycloneDX dispone anche di proprietà ufficiali cdx:device:* per i dettagli hardware come funzione, posizione sulla scheda, tipo di dispositivo, numero seriale, numero di lotto e identificatori GS1. Utilizzare tali nomi ove appropriato. Se si aggiungono proprietà personalizzate per l'aggiornabilità o lo stato di sicurezza, assegnare loro uno spazio dei nomi chiaro in modo che i lettori non le confondano con la tassonomia ufficiale di CycloneDX.

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",
  "version": 1,
  "components": [
    {
      "type": "device",
      "bom-ref": "device:esp32-wroom-32e",
      "name": "ESP32-WROOM-32E",
      "version": "Rev 3",
      "manufacturer": { "name": "Espressif Systems" },
      "description": "Wi-Fi and Bluetooth SoC module",
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf"
        }
      ],
      "properties": [
        { "name": "cdx:device:function", "value": "Wi-Fi and Bluetooth connectivity" },
        { "name": "cdx:device:deviceType", "value": "SMD module" },
        { "name": "example:firmware:updateable", "value": "vendor-supported" },
        { "name": "example:security:secure-boot", "value": "supported" }
      ]
    },
    {
      "type": "firmware",
      "bom-ref": "firmware:esp-idf-4.4.1",
      "name": "ESP-IDF",
      "version": "4.4.1",
      "description": "Espressif IoT Development Framework running on ESP32"
    },
    {
      "type": "library",
      "bom-ref": "library:mbedtls-2.28.0",
      "name": "mbedtls",
      "version": "2.28.0",
      "purl": "pkg:generic/mbedtls@2.28.0",
      "description": "TLS library in firmware"
    }
  ],
  "dependencies": [
    { "ref": "device:esp32-wroom-32e", "dependsOn": ["firmware:esp-idf-4.4.1"] },
    { "ref": "firmware:esp-idf-4.4.1", "dependsOn": ["library:mbedtls-2.28.0"] }
  ]
}

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.

L'esempio omette deliberatamente un CPE hardware. Le stringhe CPE del National Vulnerability Database (NVD) sono specifiche per prodotto e gli identificatori a livello di modulo e die non sempre coincidono. Aggiungere un campo cpe solo quando si è verificata la voce NVD esatta per il componente. Per il confronto dei formati e le scelte degli strumenti, si consulti CycloneDX vs SPDX.

L'abbinamento delle vulnerabilità hardware è diverso

Gli scanner di vulnerabilità software abbinano spesso tramite Package URL (PURL), Common Platform Enumeration (CPE) o metadati di pacchetto. L'hardware è più complesso.

PURL è costruito attorno agli ecosistemi di pacchetti software come npm, Maven, PyPI, Debian e RPM. È utile per i pacchetti firmware o le librerie in cui il software è distribuito come pacchetto. Non è l'identificatore corretto per un chip fisico.

CPE può rappresentare l'hardware tramite part=h, e CycloneDX ha un campo cpe di primo livello sui componenti. Utilizzarlo quando esiste un CPE NVD verificato. Non dare però per scontato che ogni chip, modulo o immagine firmware ne abbia uno.

Per le voci hardware prive di un CPE affidabile, mantenere il percorso di abbinamento leggibile:

• nome esatto del fabbricante
• codice articolo del fabbricante
• revisione hardware o stepping
• nome e versione del firmware
• URL degli avvisi del fornitore o PSIRT
• contatto del fornitore
• identificatore GS1 ove disponibile, usando la proprietà cdx:device:gs1:* pertinente

Monitorare quindi le fonti che pubblicano effettivamente avvisi hardware e firmware: la pagina PSIRT del fornitore, NVD, le vulnerabilità sfruttate note CISA (CISA Known Exploited Vulnerabilities), gli avvisi CISA ICS ove pertinenti e i feed specifici per settore per prodotti industriali, medicali o radio. Utilizzare VEX o prove equivalenti quando un componente è presente ma la funzione vulnerabile non è raggiungibile nel prodotto. Per il flusso di notifica, si consulti Segnalazione di vulnerabilità e incidenti CRA.

Cosa chiedere a fornitori e fabbricanti a contratto

Il fabbricante è responsabile della dovuta diligenza sui componenti. Per l'hardware, significa richiedere dati di sicurezza e ciclo di vita prima che il componente sia incorporato nel prodotto.

Richiedere a fornitori e fabbricanti a contratto:

• Identità esatta spedita: codice articolo del fabbricante, revisione hardware, versione firmware e qualsiasi sostituzione approvata.
• Percorso di aggiornamento: se il firmware è aggiornabile in campo, solo dal fornitore, solo in fabbrica o immutabile.
• Sicurezza degli aggiornamenti: dettagli su firma, autenticazione, anti-rollback e distribuzione sicura.
• Date di supporto: EOL del componente, last-time-buy, ultimo rilascio firmware e data di fine supporto.
• Canale degli avvisi: pagina PSIRT, mailing list di sicurezza, feed CSAF, portale di supporto o contatto nominato.
• Stato delle vulnerabilità note: avvisi correnti, versioni firmware corrette e qualsiasi dichiarazione VEX o CSAF.
• Tracciabilità in produzione: distinta base as-built per ciclo produttivo, lotto o intervallo di seriale in cui possono verificarsi sostituzioni.
• Percorso nella catena di fornitura: fonte del distributore autorizzato o del fabbricante originale del componente in cui il rischio di contraffazione o mercato grigio è rilevante.

Una design BOM non è sufficiente quando un original design manufacturer (ODM) o un fabbricante a contratto può sostituire i moduli durante la produzione. È necessario il registro dei componenti as-built per le unità immesse sul mercato UE.