Come Generare un Firmware SBOM: Strumenti Open Source e Workflow

Quando una vulnerabilità critica come Log4Shell o Heartbleed di OpenSSL è emersa, ogni team software si è affrettato a rispondere a una sola domanda: siamo interessati? Per i produttori di firmware, quella domanda è quasi impossibile da rispondere senza un Software Bill of Materials. Un deployment in container può interrogare il suo gestore di pacchetti in pochi secondi. Un binario firmware installato in dispositivi di produzione su un piano di fabbrica non può farlo. Senza un firmware SBOM, non hai un inventario, e senza un inventario, non puoi sapere cosa devi correggere, segnalare o sostituire.

Questa guida copre i tre percorsi pratici per generare un firmware SBOM usando strumenti open source, le sfide che rendono il firmware più difficile del software tradizionale, e come rendere operativo il risultato per la conformità CRA continuativa.

Cos'è un Firmware SBOM?

Un firmware SBOM è un inventario strutturato di tutti i componenti software contenuti in un'immagine firmware: pacchetti OS, librerie condivise, bootloader, moduli kernel, driver, e qualsiasi blob binario fornito da terzi. Gli stessi elementi minimi NTIA si applicano come per qualsiasi SBOM software: nome del fornitore, nome del componente, versione, identificatore univoco, relazioni di dipendenza, autore dei dati SBOM, e timestamp, ma sono sostanzialmente più difficili da popolare per il firmware che per un'applicazione web.

CycloneDX 1.6 definisce firmware come un tipo di componente distinto accanto all'hardware del dispositivo, il che significa che puoi modellare l'intero prodotto, livelli hardware, firmware e software, in un singolo documento CycloneDX. Questo è rilevante per la classificazione dei prodotti CRA: un router classificato come prodotto con elementi digitali deve avere i suoi componenti firmware tracciati e monitorati per l'intero periodo di supporto.

Un firmware SBOM non è un Hardware Bill of Materials (HBOM). L'HBOM documenta i componenti fisici: PCB, chip, connettori. Un firmware SBOM documenta il software in esecuzione su quell'hardware.

Perché i Firmware SBOM Sono Più Difficili degli SBOM Software

Generare un SBOM per un'applicazione web significa eseguire npm list --json o pip list. Generare uno per il firmware significa ricostruire un manifesto da artefatti che non sono mai stati progettati per essere inventariati.

L'intuizione fondamentale: la generazione di firmware SBOM è reverse engineering sotto incertezza. Stai ricostruendo un manifesto da artefatti, non generandone uno dagli input. Questa distinzione determina quale strumento e workflow dovresti scegliere.

I Due Approcci Fondamentali

Ogni workflow di firmware SBOM rientra in una di due categorie:

1. SBOM al momento della build. Generato durante il processo di build dagli input esatti del sistema di build. Massima accuratezza. Richiede accesso al build sorgente. Funziona con Yocto e Buildroot.
2. SBOM post-build / analizzato. Reverse-engineered da un'immagine firmware binaria. Minore confidenza, ma spesso l'unica opzione quando ricevi il firmware da un ODM o stai auditando un dispositivo che non hai fabbricato.

La scelta giusta dipende interamente dal fatto che tu controlli la build.

Approccio 1 — SBOM al Momento della Build con Yocto o Buildroot

Quando usarlo: Possiedi la build firmware. Questo è il gold standard per l'accuratezza.

Yocto: classe create-spdx (integrata)

La bbclass create-spdx è inclusa nelle versioni recenti di Yocto ed ereditata per impostazione predefinita tramite la configurazione di distribuzione di Poky. Non è richiesto alcun strumento aggiuntivo. Dopo una build normale, vengono generati tre file:

# After a normal Yocto build
ls tmp/deploy/spdx/
# IMAGE-MACHINE.spdx.json         ← main SPDX document
# IMAGE-MACHINE.spdx.index.json   ← per-recipe component index
# IMAGE-MACHINE.spdx.tar.zst      ← full archive with all component SBOMs

Lo SBOM generato include tutti i componenti software, le versioni esatte, le licenze, gli URL sorgente, le patch applicate e le relazioni di dipendenza. Non c'è incertezza di estrazione: lo SBOM è derivato dagli stessi input che hanno prodotto il binario.

Per eseguire anche l'analisi CVE al momento della build:

# Add to local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Vedere la documentazione SBOM di Yocto per le opzioni di configurazione complete.

Buildroot: make legal-info + generatore CycloneDX

# Step 1: Generate the component manifest
make legal-info
# Output: output/legal-info/manifest.csv

# Step 2: Convert to CycloneDX SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: scan for CVEs at build time
python support/scripts/cve-check --nvd-path ./nvd-data/

Il convertitore cyclonedx-buildroot produce un output JSON CycloneDX dal manifesto legale di Buildroot, rendendolo immediatamente utilizzabile per la conformità CRA.

Limitazione nota: I blob binari di terze parti aggiunti alla build (firmware Wi-Fi, blob GPU) vengono tracciati solo se li aggiungi manualmente come pacchetti Yocto o Buildroot. Se il tuo sistema di build non conosce un blob, nemmeno lo SBOM lo conoscerà.

Approccio 2 — Analisi di un Binario Esistente

Quando usarlo: Hai ricevuto il firmware da un ODM o OEM, o stai auditando un dispositivo che non costruisci tu stesso.

Passo 1: Estrarre il firmware con binwalk

binwalk v3, la riscrittura in Rust dello strumento originale, fornisce un'estrazione più veloce e un migliore supporto dei formati per le immagini firmware moderne:

# Install binwalk v3
pip install binwalk

# Extract all embedded filesystems
binwalk -eM firmware.bin

# Check what got extracted
ls _firmware.bin.extracted/

# Check for encrypted partitions before proceeding
binwalk -E firmware.bin
# High entropy (above 0.9) regions indicate encrypted content

Passo 2a: Identificare la distribuzione Linux ed eseguire Syft

Se il filesystem estratto contiene una distribuzione Linux embedded standard (OpenWRT, basata su Debian, basata su Alpine):

# Check for package manager databases
ls _firmware.bin.extracted/squashfs-root/var/lib/dpkg/    # Debian-based
ls _firmware.bin.extracted/squashfs-root/lib/apk/db/      # Alpine/musl-based
ls _firmware.bin.extracted/squashfs-root/var/lib/opkg/    # OpenWRT/opkg

# Run Syft on the extracted filesystem
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft legge i database dei gestori di pacchetti e genera uno SBOM con alta confidenza per i componenti pacchettizzati. Non vede le librerie C/C++ compilate personalizzate che sono state compilate direttamente nel binario.

Passo 2b: Scansionare i binari per le librerie vulnerabili note con cve-bin-tool

# Install Intel's cve-bin-tool
pip install cve-bin-tool

# Scan extracted binary directory
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool utilizza la corrispondenza di pattern di stringhe contro firme per oltre 447 librerie embedded note: OpenSSL, libpng, libxml2, expat, zlib, curl, e altro. Copre ciò che Syft manca.

Passo 2c: Analisi approfondita del firmware con EMBA

Per un'analisi completa che combina estrazione, generazione SBOM, e una revisione completa della sicurezza in un singolo workflow:

# Clone and set up EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Run EMBA with SBOM output
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA gestisce l'estrazione internamente, identifica i componenti attraverso multiple strategie parallele, genera uno SBOM CycloneDX con dati VEX, e produce un report completo sulle vulnerabilità. È l'opzione open source più completa per l'analisi di firmware black-box.

Riferimento degli Strumenti — Confronto Rapido

SPDX vs CycloneDX: Entrambi i formati sono ampiamente accettati. CycloneDX ha un tipo di componente firmware nativo e supporto VEX integrato, rendendolo la scelta migliore per la conformità CRA. SPDX è preferito nei contesti di conformità alle licenze open source. Per il CRA, genera CycloneDX.

Gestire il Tuo Firmware SBOM nel Tempo

Un SBOM una tantum è un'istantanea. Per la conformità CRA, hai bisogno di uno SBOM operativo che si evolve con il tuo prodotto.

Build → SBOM (CycloneDX) → Dependency-Track → CVE alert → VEX statement → ENISA report (if exploited)

Quattro passi per rendere questo operativo:

1. Rigenerare ad ogni build firmware. Integra la generazione SBOM di Yocto o Buildroot nel tuo pipeline CI/CD.
2. Caricare su Dependency-Track. Monitora il tuo SBOM contro feed CVE in tempo reale e ti avvisa delle nuove vulnerabilità.
3. Emettere dichiarazioni VEX. Documenta se il prodotto è affected, not_affected, fixed, o under_investigation. Vedere la guida VEX.
4. Segnalare all'ENISA. Da settembre 2026. Vedere la guida alla segnalazione ENISA.

Errori Comuni da Evitare

1. Fidarsi di Syft da solo per il firmware. Syft vede solo i componenti gestiti da un gestore di pacchetti. Combina sempre con cve-bin-tool o blint.

2. Ignorare le regioni ad alta entropia. binwalk salta silenziosamente le partizioni cifrate. Esegui prima l'analisi dell'entropia (binwalk -E); documenta le lacune nello SBOM.

3. Dimenticare il bootloader. U-Boot, coreboot e GRUB sono componenti firmware con vere CVE. Si trovano al di fuori del filesystem OS e vengono mancati dalla maggior parte degli strumenti.

4. Trattare gli SBOM analizzati come autorevoli. Un SBOM post-build è un'approssimazione. Contrassegna i componenti con livelli di confidenza usando il campo evidence di CycloneDX.

5. Nessun piano del ciclo di vita. Nuove CVE vengono pubblicate ogni giorno. Senza Dependency-Track, il tuo SBOM diventa obsoleto in poche settimane.

6. Lacuna dei blob ODM. Richiedi contrattualmente la consegna dello SBOM da tutti i fornitori di firmware. Questo non è opzionale sotto il CRA.

Lista di Controllo della Conformità CRA per i Produttori di Firmware

□ Identificare tutti i componenti firmware nei tuoi prodotti (lo SBOM)
□ Scegliere il tuo approccio: al momento della build (Yocto/Buildroot) o post-build (EMBA/Syft/cve-bin-tool)
□ Generare lo SBOM in formato JSON CycloneDX (usa anche SPDX per la conformità alle licenze open source)
□ Includere bootloader, kernel, tutti i pacchetti userspace, e qualsiasi blob vendor (o documentarli come lacune)
□ Importare lo SBOM in Dependency-Track (o equivalente) per il monitoraggio continuo
□ Stabilire un workflow VEX per documentare lo stato di sfruttabilità delle CVE
□ Configurare il pipeline di segnalazione pronto per l'ENISA da settembre 2026
□ Richiedere la consegna dello SBOM da tutti i fornitori di componenti firmware (ODM, vendor di chip)
□ Rigenerare lo SBOM ad ogni build firmware e tracciare le modifiche nel tempo
□ Documentare la tua metodologia di generazione SBOM per scopi di audit

Come CRA Evidence Aiuta

CRA Evidence traccia i tuoi firmware SBOM insieme ai Passaporti Digitali dei Prodotti, alle valutazioni di conformità e alla documentazione tecnica in un unico spazio di lavoro per la conformità. Carica direttamente il tuo SBOM CycloneDX su una versione del prodotto: diventa l'inventario dei componenti in tempo reale per quella release.

Carica il tuo primo SBOM o inizia una prova gratuita.

I firmware SBOM non sono opzionali sotto il CRA: sono il fondamento di tutto ciò che il regolamento richiede: conoscere i tuoi componenti, monitorare le vulnerabilità e segnalare gli incidenti. Scegli il workflow giusto per la tua situazione, al momento della build se puoi, analisi binaria se devi, e rendilo operativo prima della scadenza per la segnalazione di settembre 2026.