Hoe een Firmware SBOM te Genereren: Open Source 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 drie praktische 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 operationeel kunt maken voor doorlopende CRA-naleving.

Samenvatting

• Twee paden: build-time (Yocto/Buildroot, hoogste nauwkeurigheid) of post-build binaire analyse (EMBA/Syft/cve-bin-tool, best effort)
• Kies op basis van controle: als u de build beheert, gebruik build-time; als u firmware van een ODM heeft ontvangen, gebruik binaire analyse
• Voor binaire analyse: extraheer met binwalk, scan verpakte componenten met Syft, scan gestripte binaries met cve-bin-tool, of voer een volledige audit uit met EMBA
• Genereer in CycloneDX JSON voor CRA-naleving; voeg SPDX toe als u ook open source-licentienaleving nodig heeft
• Push naar Dependency-Track voor doorlopende CVE-monitoring en VEX-workflowbeheer
• ENISA-rapportage begint 11 september 2026: u heeft een operationele pipeline nodig vóór die datum, niet december 2027
• ODM-firmware is uw wettelijke verantwoordelijkheid onder de CRA: eis SBOM-levering van alle firmwareleveranciers

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.

CRA Link: De EU Cyber Resilience Act (Bijlage I) vereist dat fabrikanten kwetsbaarheden gedurende de volledige productlevenscyclus beheren. Een SBOM is de praktische basis: u kunt niet patchen wat u niet heeft gecatalogiseerd. 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 Firmware SBOM's Moeilijker zijn dan Software SBOM's

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)

De create-spdx bbclass is opgenomen in recente Yocto-releases en wordt standaard geïnheriteerd via Poky's distro-configuratie. Er is geen extra tooling nodig. Na een normale build worden drie bestanden gegenereerd:

# 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

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:

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

Zie de Yocto SBOM-documentatie voor volledige configuratieopties.

Buildroot: make legal-info + CycloneDX-generator

# 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/

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.

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 v3, de Rust-herschrijving van de originele tool, biedt snellere extractie en verbeterde formaatondersteuning voor moderne firmware-images:

# 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

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):

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

# 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 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 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 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. Genereer voor CRA CycloneDX. SPDX heeft de voorkeur voor open source-licentienaleving.

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.

Build → SBOM (CycloneDX) → Dependency-Track → CVE-melding → VEX-verklaring → ENISA-rapport (indien uitgebuit)

Vier 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. Geef VEX-verklaringen af. Documenteer of het product affected, not_affected, fixed of under_investigation is. Zie de VEX-handleiding.
4. Rapporteer aan ENISA. Vanaf september 2026. Zie de ENISA-rapportagehandleiding.

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

Deadline: De belangrijkste CRA-verplichtingen gelden vanaf 11 december 2027. Kwetsbaarheidsrapportage aan ENISA begint op 11 september 2026. U heeft een operationele SBOM-pipeline nodig vóór september 2026. Zie de CRA-implementatietijdlijn.

□ 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

Hoe CRA Evidence Helpt

CRA Evidence volgt uw firmware SBOM's samen met Digital Product Passports, conformiteitsbeoordelingen en technische documentatie in één compliance-werkruimte. Upload uw CycloneDX SBOM rechtstreeks naar een productversie, het wordt de live componenteninventaris voor die release.

Upload uw eerste SBOM of start een gratis proefperiode.

Firmware SBOM's zijn niet optioneel onder de CRA, ze zijn de basis van alles wat de verordening vereist. Kies de juiste workflow voor uw situatie, build-time indien mogelijk, binaire analyse indien noodzakelijk, en maak het operationeel vóór de rapportagedeadline van september 2026.