Een firmware-SBOM genereren: tools en workflows

Toen een kritieke kwetsbaarheid zoals Log4Shell of OpenSSL's Heartbleed opdook, had elk softwareteam één brandende vraag: zijn wij getroffen? Voor firmwarefabrikanten is die vraag vrijwel onmogelijk te beantwoorden zonder een Software Bill of Materials. Een containerdeployment kan in seconden zijn pakketbeheerder raadplegen. Een firmware-binary die in productieapparaten op een fabriekshal staat, niet. Zonder een firmware SBOM heeft u geen inventaris, en zonder inventaris weet u niet wat u moet patchen, rapporteren of vervangen.

Deze handleiding behandelt de twee paden voor het genereren van een firmware SBOM met open source tools, de uitdagingen die firmware moeilijker maken dan software, en hoe u het resultaat gebruikt voor doorlopende CRA-naleving.

Wat is een Firmware SBOM?

Een firmware SBOM is een gestructureerde inventaris van alle softwarecomponenten in een firmware-image: OS-pakketten, gedeelde bibliotheken, bootloaders, kernelmodules, drivers en eventuele vendored binary blobs. Dezelfde NTIA-minimumelementen zijn van toepassing als voor elke software SBOM: naam van de leverancier, componentnaam, versie, unieke identifier, afhankelijkheidsrelaties, auteur van de SBOM-gegevens en tijdstempel, maar ze zijn voor firmware aanzienlijk moeilijker in te vullen dan voor een webapplicatie.

CycloneDX 1.6 definieert firmware als een apart componenttype naast apparaathardware, wat betekent dat u het volledige product, hardware-, firmware- en softwarelagen, in één CycloneDX-document kunt modelleren. Dit is relevant voor CRA-productclassificatie: een router die is geclassificeerd als een product met digitale elementen moet zijn firmwarecomponenten bijhouden en bewaken gedurende de volledige ondersteuningsperiode.

Bijlage I, deel II van de CRA vereist dat fabrikanten:

"1) kwetsbaarheden en componenten in producten met digitale elementen vaststellen en documenteren, onder meer door een softwarestuklijst op te stellen in een algemeen gebruikt en machineleesbaar formaat waarin ten minste de afhankelijkheden van de producten op het hoogste niveau worden aangegeven;"

Voor firmware betekent "afhankelijkheden op het hoogste niveau" elk OS-pakket, elke gedeelde bibliotheek, elke bootloader en elke kernelmodule in de image, niet alleen wat een pakketbeheerder rapporteert.

Zie SBOM-vereisten onder de CRA voor de volledige regelgevende context.

Een firmware SBOM is geen Hardware Bill of Materials (HBOM). De HBOM documenteert fysieke componenten: PCB's, chips, connectoren. Een firmware SBOM documenteert de software die op die hardware draait.

Waarom is het Genereren van een Firmware SBOM Moeilijker dan een Standaard Software SBOM?

Het genereren van een SBOM voor een webapplicatie betekent npm list --json of pip list uitvoeren. Het genereren van een SBOM voor firmware betekent een manifest reconstrueren uit artefacten die nooit zijn ontworpen om geïnventariseerd te worden.

De kerngedachte: firmware SBOM-generatie is reverse engineering onder onzekerheid. U reconstrueert een manifest uit artefacten in plaats van het te genereren uit invoer. Dit onderscheid bepaalt welk tool en welke workflow u kiest.

De Twee Fundamentele Benaderingen

Elke firmware SBOM-workflow valt in één van twee categorieën:

1. Build-time SBOM. Gegenereerd tijdens het bouwproces vanuit de exacte invoer van het buildsysteem. Hoogste nauwkeurigheid. Vereist toegang tot de bronbuild. Werkt met Yocto en Buildroot.
2. Post-build / geanalyseerde SBOM. Reverse-engineered vanuit een firmware-binary image. Lagere betrouwbaarheid, maar vaak de enige optie wanneer u firmware ontvangt van een ODM of een apparaat auditeert dat u zelf niet heeft gebouwd.

De juiste keuze hangt volledig af van of u de build beheert.

Benadering 1: Build-Time SBOM met Yocto of Buildroot

Wanneer te gebruiken: U heeft de firmware-build in eigen beheer. Dit is de gouden standaard voor nauwkeurigheid.

Yocto: create-spdx klasse (ingebouwd)

Het OpenEmbedded-buildsysteem genereert standaard SPDX-SBOM-gegevens door create-spdx te erven via INHERIT_DISTRO. Na een normale image-build staat de belangrijkste SPDX JSON in de deploy-directory van de image:

# Na een normale Yocto-imagebuild
ls tmp/deploy/images/MACHINE/
# IMAGE-MACHINE.spdx.json         ← hoofd-SPDX-document
# SBOM-metadata van recepten is opgenomen voor recepten in de image

De gegenereerde SBOM bevat alle softwarecomponenten, exacte versies, licenties, bron-URL's, toegepaste patches en afhankelijkheidsrelaties. Er is geen extractieonzekerheid, de SBOM wordt afgeleid uit dezelfde invoer die de binary heeft geproduceerd.

Om ook CVE-analyse uit te voeren tijdens de build:

# Voeg toe aan local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Zie de Yocto SBOM-documentatie voor volledige configuratieopties.

Buildroot: make legal-info + CycloneDX-generator

# Stap 1: Genereer het componentenmanifest
make legal-info
# Uitvoer: output/legal-info/manifest.csv

# Stap 2: Converteer naar CycloneDX-SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optioneel: scan op CVE's tijdens de build
python support/scripts/cve-check --nvd-path ./nvd-data/

De cyclonedx-buildroot-converter produceert een CycloneDX JSON-uitvoer vanuit Buildroot's wettelijk manifest, waardoor het direct bruikbaar is voor CRA-naleving.

Bekende beperking: Binaire blobs van derden die aan de build worden toegevoegd (Wi-Fi firmware, GPU blobs) worden alleen bijgehouden als u ze handmatig als Yocto- of Buildroot-pakketten toevoegt. Als uw buildsysteem een blob niet kent, kent de SBOM die ook niet.

Zephyr RTOS: west spdx

Zephyr genereert SBOM's native via het commando west spdx. Standaard levert dit SPDX 2.3-documenten in tag-value-formaat op:

west spdx --init -d build
west build -d build -b <your_board> <app_dir>
west spdx -d build

De uitvoer staat in build/spdx/ en bevat app.spdx, zephyr.spdx, build.spdx en modules-deps.spdx. Binaire blobs van derden of out-of-tree bibliotheken die niet door de buildmetadata worden gedekt, ontbreken. Documenteer die leemtes of voeg ze handmatig toe als externe componenten.

Voor FreeRTOS en bare-metal RTOS-platformen zonder native SBOM-tooling scant u de gecompileerde binary met cve-bin-tool. Registreer de RTOS-kernelversie en opgenomen middleware handmatig als CycloneDX-componenten.

Benadering 2: Analyseren van een Bestaand Binary

Wanneer te gebruiken: U heeft firmware ontvangen van een ODM of OEM, of u auditeert een apparaat dat u zelf niet bouwt.

Stap 1: Extraheer de firmware met binwalk

binwalk is de standaard open source-tool voor het uitpakken van firmware:

# Installeer binwalk
pip install binwalk

# Extraheer alle embedded bestandssystemen
binwalk -eM firmware.bin

# Controleer wat is geëxtraheerd
ls _firmware.bin.extracted/

# Controleer op versleutelde partities voordat u doorgaat
binwalk -E firmware.bin
# Hoge entropie (boven 0.9) wijst op versleutelde inhoud

Let op: ReFirmLabs onderhoudt ook een Rust-herschrijving die u kunt installeren met cargo install binwalk. Beide versies werken voor de stappen hieronder; de commandoflags zijn hetzelfde.

Stap 2a: Identificeer de Linux-distributie en voer Syft uit

Als het geëxtraheerde bestandssysteem een standaard embedded Linux-distributie bevat (OpenWRT, Debian-gebaseerd, Alpine-gebaseerd):

# Controleer pakketbeheerdatabases
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

# Voer Syft uit op het geëxtraheerde bestandssysteem
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft leest pakketbeheerdersdatabases en genereert een SBOM met hoge betrouwbaarheid voor verpakte componenten. Het ziet geen aangepaste C/C++ bibliotheken die rechtstreeks in de binary zijn gecompileerd.

Stap 2b: Scan binaries op bekende kwetsbare bibliotheken met cve-bin-tool

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

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

cve-bin-tool gebruikt stringpatroonmatching tegen handtekeningen voor 447+ bekende embedded bibliotheken: OpenSSL, libpng, libxml2, expat, zlib, curl en meer. Het dekt wat Syft mist.

Stap 2c: Diepgaande firmware-analyse met EMBA

Voor een uitgebreide analyse die extractie, SBOM-generatie en een volledige beveiligingsbeoordeling combineert in één workflow:

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

# Voer EMBA uit met SBOM-output
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA verwerkt de extractie intern, identificeert componenten via meerdere parallelle strategieën, geeft een CycloneDX SBOM met VEX-gegevens uit en genereert een volledig kwetsbaarheidsrapport.

Toolreferentie: Snelle Vergelijking

SPDX vs CycloneDX: Beide formaten worden breed geaccepteerd. CycloneDX heeft een native firmware-componenttype en ingebouwde VEX-ondersteuning, waardoor het beter past bij CRA-naleving. SPDX heeft de voorkeur voor open source-licentienaleving en is de native output van Yocto. Genereer voor CRA CycloneDX. Gebruikt u Yocto, genereer dan beide. BSI TR-03183-2 v2.1.0, de Duitse BSI-richtlijn voor SBOM onder de CRA, beveelt CycloneDX 1.6+ of SPDX 3.0.1+ aan en is het document dat auditors en aangemelde instanties het vaakst citeren.

Uw Firmware SBOM in de Loop van de Tijd Beheren

Een eenmalige SBOM is een momentopname. Voor CRA-naleving heeft u een operationele SBOM nodig die evolueert met uw product.

Vijf stappen om dit operationeel te maken:

1. Regenereer bij elke firmware-build. Koppel Yocto- of Buildroot SBOM-generatie aan uw CI/CD-pipeline.

2. Push naar Dependency-Track. Bewaakt uw SBOM tegen live CVE-feeds en waarschuwt u voor nieuwe kwetsbaarheden.

3. Onderteken de SBOM. Onderteken het gegenereerde bestand met cosign van Sigstore voordat u het opslaat of deelt:

   cosign sign-blob sbom.cdx.json \
     --bundle sbom.cdx.json.bundle \
     --yes
   

   Bewaar de bundle naast de SBOM. Klanten en autoriteiten kunnen deze verifiëren met cosign verify-blob. De CRA vereist dit vandaag niet, maar supply-chain security frameworks zoals SLSA en in-toto verwachten het.

4. Geef VEX-verklaringen af. Documenteer of het product affected, not_affected, fixed of under_investigation is. Zie de VEX-handleiding.

5. Meld aan ENISA. Vanaf september 2026. Zie de ENISA-meldingshandleiding.

Veelgemaakte Fouten om te Vermijden

1. Uitsluitend vertrouwen op Syft voor firmware. Syft ziet alleen door pakketbeheer beheerde componenten. Combineer altijd met cve-bin-tool of blint.

2. Hoge-entropiegebieden negeren. binwalk slaat versleutelde partities stilletjes over. Voer eerst binwalk -E uit; documenteer leemtes expliciet.

3. De bootloader vergeten. U-Boot, coreboot en GRUB zijn firmwarecomponenten met echte CVE's die de meeste tools missen.

4. Geanalyseerde SBOM's als gezaghebbend behandelen. Markeer componenten met betrouwbaarheidsniveaus via het evidence-veld van CycloneDX.

5. Geen levenscyclusplan. Zonder Dependency-Track wordt uw SBOM binnen weken verouderd.

6. ODM blob-leemte. Eis SBOM-levering contractueel van alle firmwareleveranciers. U bent verantwoordelijk onder de CRA.

CRA-nalevingschecklist voor Firmwarefabrikanten

□ Identificeer alle firmwarecomponenten in uw producten (de SBOM)
□ Kies uw aanpak: build-time (Yocto/Buildroot) of post-build (EMBA/Syft/cve-bin-tool)
□ Genereer SBOM in CycloneDX JSON-formaat (gebruik ook SPDX voor open source-licentienaleving)
□ Neem bootloader, kernel, alle userspace-pakketten en eventuele vendor blobs op (of documenteer ze als leemtes)
□ Importeer SBOM in Dependency-Track (of equivalent) voor doorlopende monitoring
□ Stel een VEX-workflow in voor het documenteren van exploiteerbaarheid van CVE's
□ Stel rapportagepipeline in klaar voor ENISA vanaf september 2026
□ Eis SBOM-levering van alle firmwarecomponentleveranciers (ODM's, chipfabrikanten)
□ Regenereer SBOM bij elke firmware-build en volg wijzigingen in de loop van de tijd
□ Documenteer uw SBOM-generatiemethodologie voor auditdoeleinden