Wie man ein Firmware-SBOM erstellt: Open-Source-Tools und Workflows

Als eine kritische Schwachstelle wie Log4Shell oder OpenSSLs Heartbleed bekannt wurde, stand jedes Software-Team vor derselben Frage: Sind wir betroffen? Für Firmware-Hersteller ist diese Frage ohne ein Software Bill of Materials nahezu unmöglich zu beantworten. Ein Container-Deployment kann seinen Paketmanager in Sekunden abfragen. Eine Firmware-Binärdatei, die in Produktionsgeräten auf einer Fabrikhalle läuft, kann das nicht. Ohne ein Firmware-SBOM haben Sie kein Inventar, und ohne Inventar wissen Sie nicht, was gepatcht, gemeldet oder ersetzt werden muss.

Dieser Leitfaden behandelt die drei praktischen Wege zur Erstellung eines Firmware-SBOM mit Open-Source-Tools, die Herausforderungen, die Firmware schwieriger als Software machen, und wie das Ergebnis für die laufende CRA-Compliance operationalisiert werden kann.

Was ist ein Firmware-SBOM?

Ein Firmware-SBOM ist ein strukturiertes Inventar aller Softwarekomponenten, die in einem Firmware-Image enthalten sind: OS-Pakete, gemeinsam genutzte Bibliotheken, Bootloader, Kernel-Module, Treiber und alle herstellerspezifischen binären Blobs. Dieselben NTIA-Mindestelemente gelten wie für jedes Software-SBOM: Lieferantenname, Komponentenname, Version, eindeutiger Bezeichner, Abhängigkeitsbeziehungen, Autor der SBOM-Daten und Zeitstempel, sind jedoch für Firmware wesentlich schwieriger zu befüllen als für eine Webanwendung.

CycloneDX 1.6 definiert firmware als eigenständigen Komponententyp neben Gerätehardware, was bedeutet, dass Sie das gesamte Produkt, Hardware-, Firmware- und Softwareschichten, in einem einzigen CycloneDX-Dokument modellieren können. Dies ist relevant für die CRA-Produktklassifizierung: Ein als Produkt mit digitalen Elementen eingestufter Router muss seine Firmware-Komponenten über den gesamten Supportzeitraum verfolgt und überwacht haben.

Ein Firmware-SBOM ist kein Hardware Bill of Materials (HBOM). Das HBOM dokumentiert physische Komponenten: Leiterplatten, Chips, Steckverbinder. Ein Firmware-SBOM dokumentiert die Software, die auf dieser Hardware läuft.

Warum Firmware-SBOMs schwieriger sind als Software-SBOMs

Ein SBOM für eine Webanwendung zu erstellen bedeutet, npm list --json oder pip list auszuführen. Ein SBOM für Firmware zu erstellen bedeutet, ein Manifest aus Artefakten zu rekonstruieren, die nie für eine Inventarisierung konzipiert wurden.

Die zentrale Erkenntnis: Firmware-SBOM-Generierung ist Reverse Engineering unter Unsicherheit. Sie rekonstruieren ein Manifest aus Artefakten, anstatt eines aus Inputs zu generieren. Diese Unterscheidung bestimmt, welches Tool und welchen Workflow Sie wählen sollten.

Die zwei grundlegenden Ansätze

Jeder Firmware-SBOM-Workflow fällt in eine von zwei Kategorien:

1. Build-Zeit-SBOM. Während des Build-Prozesses aus den exakten Inputs des Build-Systems generiert. Höchste Genauigkeit. Erfordert Zugang zum Quell-Build. Funktioniert mit Yocto und Buildroot.
2. Post-Build / analysiertes SBOM. Aus einem Firmware-Binär-Image reverse-engineered. Geringere Konfidenz, aber oft die einzige Option, wenn Sie Firmware von einem ODM erhalten oder ein Gerät auditieren, das Sie nicht selbst hergestellt haben.

Die richtige Wahl hängt vollständig davon ab, ob Sie den Build kontrollieren.

Ansatz 1 — Build-Zeit-SBOM mit Yocto oder Buildroot

Wann verwenden: Sie besitzen den Firmware-Build. Dies ist der Goldstandard für Genauigkeit.

Yocto: create-spdx-Klasse (eingebaut)

Die create-spdx-bbclass ist in neueren Yocto-Releases enthalten und wird standardmäßig über Pokys Distro-Konfiguration eingebunden. Es sind keine zusätzlichen Tools erforderlich. Nach einem normalen Build werden drei Dateien generiert:

# 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

Das generierte SBOM enthält alle Softwarekomponenten, exakte Versionen, Lizenzen, Quell-URLs, angewandte Patches und Abhängigkeitsbeziehungen. Es gibt keine Extraktionsunsicherheit, das SBOM wird aus denselben Inputs abgeleitet, die das Binary produziert haben.

Um auch zur Build-Zeit eine CVE-Analyse durchzuführen:

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

Vollständige Konfigurationsoptionen finden Sie in der Yocto-SBOM-Dokumentation.

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/

Der cyclonedx-buildroot-Konverter erzeugt eine CycloneDX-JSON-Ausgabe aus Buildrootss Legal-Manifest, die sofort für die CRA-Compliance verwendbar ist.

Bekannte Einschränkung: Drittanbieter-Binär-Blobs, die dem Build hinzugefügt werden (Wi-Fi-Firmware, GPU-Blobs), werden nur verfolgt, wenn Sie sie manuell als Yocto- oder Buildroot-Pakete hinzufügen. Wenn Ihr Build-System nichts von einem Blob weiß, wird das SBOM es auch nicht wissen.

Ansatz 2 — Analyse einer vorhandenen Binärdatei

Wann verwenden: Sie haben Firmware von einem ODM oder OEM erhalten, oder Sie auditieren ein Gerät, das Sie nicht selbst bauen.

Schritt 1: Firmware mit binwalk extrahieren

binwalk v3, das Rust-Rewrite des ursprünglichen Tools, bietet schnellere Extraktion und verbesserte Formatunterstützung für 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

Schritt 2a: Linux-Distribution identifizieren und Syft ausführen

Wenn das extrahierte Dateisystem eine standardmäßige eingebettete Linux-Distribution enthält (OpenWRT, Debian-basiert, Alpine-basiert):

# 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 liest Paketmanager-Datenbanken und generiert ein SBOM mit hoher Konfidenz für paketierte Komponenten. Es sieht keine custom-kompilierten C/C++-Bibliotheken, die direkt in das Binary kompiliert wurden. Dafür benötigen Sie Schritt 2b.

Schritt 2b: Binärdateien auf bekannte anfällige Bibliotheken mit cve-bin-tool scannen

# 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 verwendet String-Mustererkennung gegen Signaturen für 447+ bekannte eingebettete Bibliotheken: OpenSSL, libpng, libxml2, expat, zlib, curl und mehr. Es deckt ab, was Syft übersieht: Bibliotheken, die kompiliert und in das Binary eingestreift wurden, ohne Paketdatenbankeintrag.

Schritt 2c: Tiefgreifende Firmware-Analyse mit EMBA

Für eine umfassende Analyse, die Extraktion, SBOM-Generierung und eine vollständige Sicherheitsüberprüfung in einem einzigen Workflow kombiniert:

# 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 übernimmt die Extraktion intern, identifiziert Komponenten durch mehrere parallele Strategien (String-Matching, Binary-Hashing, Dateisystemanalyse, CVE-Datenbankabfragen), gibt ein CycloneDX-SBOM mit VEX-Daten aus und generiert einen vollständigen Schwachstellenbericht. Es ist die umfassendste Open-Source-Option für Black-Box-Firmware-Analysen und besonders nützlich für Drittanbieter-Firmware-Audits.

Tool-Referenz — Kurzvergleich

SPDX vs CycloneDX: Beide Formate werden weitgehend akzeptiert. CycloneDX hat einen nativen firmware-Komponententyp und eingebaute VEX-Unterstützung, was es zur besseren Wahl für die CRA-Compliance macht. SPDX ist in Open-Source-Lizenz-Compliance-Kontexten bevorzugt und Yoctos native Ausgabe. Für CRA: CycloneDX generieren. Wenn Sie Yocto verwenden: beide generieren.

Ihr Firmware-SBOM im Laufe der Zeit verwalten

Ein einmaliges SBOM ist ein Schnappschuss. Für die CRA-Compliance benötigen Sie ein operatives SBOM, das sich mit Ihrem Produkt weiterentwickelt.

Build → SBOM (CycloneDX) → Dependency-Track → CVE-Alarm → VEX-Aussage → ENISA-Bericht (bei Ausnutzung)

Vier Schritte, um dies operativ zu machen:

1. Bei jedem Firmware-Build neu generieren. Hängen Sie die Yocto- oder Buildroot-SBOM-Generierung in Ihre CI/CD-Pipeline ein, sodass jedes Release automatisch ein frisches SBOM erzeugt.
2. An Dependency-Track übergeben. OWASPs Dependency-Track überwacht Ihr SBOM gegen Live-CVE-Feeds (NVD, OSV, GitHub Advisory) und benachrichtigt Sie, wenn neue Schwachstellen vorhandene Komponenten betreffen.
3. VEX-Aussagen ausstellen. Wenn eine CVE in einer Komponente gefunden wird, dokumentieren Sie, ob das Produkt affected, not_affected, fixed oder under_investigation ist. CycloneDX VEX ist das Format; Dependency-Track verwaltet den Workflow. Einzelheiten zum Prozess finden Sie im VEX-Leitfaden.
4. An ENISA melden. Ab September 2026 schreibt die CRA die Meldung aktiv ausgenutzter Schwachstellen an ENISA innerhalb von 24 Stunden vor. Den genauen Workflow finden Sie im ENISA-Meldungsleitfaden. Dependency-Track in Kombination mit VEX ist die operative Grundlage, die Sie dafür benötigen.

Häufige Fehler, die vermieden werden sollten

1. Nur auf Syft vertrauen bei Firmware. Syft sieht nur paketverwaltete Komponenten. Jede Bibliothek, die direkt in das Binary kompiliert wurde, ohne Paketdatenbankeintrag, ist unsichtbar. Kombinieren Sie Syft immer mit cve-bin-tool oder blint.

2. Hochentropie-Bereiche ignorieren. binwalk überspringt verschlüsselte Partitionen stillschweigend. Führen Sie vor der Extraktion eine Entropieanalyse durch (binwalk -E); dokumentieren Sie alle Lücken explizit im SBOM.

3. Den Bootloader vergessen. U-Boot, coreboot und GRUB sind Firmware-Komponenten mit realen CVEs. Sie befinden sich außerhalb des OS-Dateisystems und werden von den meisten Tools übersehen, wenn sie nicht explizit angesteuert werden. Ihr SBOM muss den Bootloader enthalten.

4. Analysierte SBOMs als autoritativ behandeln. Ein post-build reverse-engineertes SBOM ist eine Annäherung. Markieren Sie Komponenten mit Konfidenzwerten. Verwenden Sie CycloneDXs evidence-Feld, um zu dokumentieren, wie jede Komponente identifiziert wurde: String-Match, Paketdatenbank, Binary-Hash oder manuelle Eingabe.

5. Kein Lifecycle-Plan. Ein SBOM zu einem einzigen Zeitpunkt erfüllt keine Compliance-Anforderung. Täglich werden neue CVEs veröffentlicht. Ohne laufendes Monitoring über Dependency-Track oder ein äquivalentes Tool wird Ihr SBOM innerhalb von Wochen veraltet.

6. ODM-Blob-Lücke. Wenn Ihre Hardware mit Firmware von einem ODM oder Chip-Hersteller ausgeliefert wird, können Sie nicht analysieren, was Sie nicht gebaut haben. Lösen Sie dies vertraglich: Fordern Sie SBOM-Lieferung von Ihren Firmware-Lieferanten. Dies ist unter der CRA nicht optional, Sie sind für das gesamte Produkt verantwortlich.

CRA-Compliance-Checkliste für Firmware-Hersteller

Frist: Die CRA-Hauptverpflichtungen gelten ab dem 11. Dezember 2027. Die Schwachstellenmeldung an ENISA beginnt am 11. September 2026. Sie benötigen eine operative SBOM-Pipeline vor September 2026, nicht Dezember 2027. Den vollständigen Überblick finden Sie auf der CRA-Implementierungszeitraum-Seite.

□ Alle Firmware-Komponenten in Ihren Produkten identifizieren (das SBOM)
□ Ansatz wählen: Build-Zeit (Yocto/Buildroot) oder Post-Build (EMBA/Syft/cve-bin-tool)
□ SBOM im CycloneDX-JSON-Format generieren (zusätzlich SPDX für Open-Source-Lizenz-Compliance)
□ Bootloader, Kernel, alle Userspace-Pakete und etwaige Hersteller-Blobs einschließen (oder als Lücken dokumentieren)
□ SBOM in Dependency-Track (oder äquivalent) einpflegen für laufendes Monitoring
□ VEX-Workflow für die Dokumentation des Ausnutzungsstatus von CVEs etablieren
□ Melde-Pipeline für ENISA ab September 2026 einrichten
□ SBOM-Lieferung von allen Firmware-Komponentenlieferanten (ODMs, Chip-Hersteller) einfordern
□ SBOM bei jedem Firmware-Build neu generieren und Änderungen über die Zeit verfolgen
□ SBOM-Generierungsmethodik für Audit-Zwecke dokumentieren

Wie CRA Evidence hilft

CRA Evidence verfolgt Ihre Firmware-SBOMs neben Digital Product Passports, Konformitätsbewertungen und technischer Dokumentation in einem einzigen Compliance-Workspace. Laden Sie Ihr CycloneDX-SBOM direkt in eine Produktversion hoch, es wird zum Live-Komponenteninventar für dieses Release, verknüpft mit Ihren Schwachstellenberichten und VEX-Aussagen. Wenn eine ENISA-Meldung erforderlich ist, sind die Daten bereits strukturiert und zugänglich.

Erstes SBOM hochladen oder kostenlose Testversion starten, um zu sehen, wie es sich in Ihren Firmware-Workflow integriert.

Firmware-SBOMs sind unter der CRA nicht optional, sie sind das Fundament für alles, was die Verordnung verlangt: Ihre Komponenten kennen, Schwachstellen überwachen und Vorfälle melden. Die Tools existieren, die Workflows sind erprobt, und der Mangel an praktischen Anleitungen in diesem Bereich bedeutet, dass ein früher Start Ihnen sowohl einen Compliance-Vorteil als auch eine Dokumentation verschafft, die Sie mit Kunden und Behörden teilen können. Wählen Sie den richtigen Workflow für Ihre Situation, Build-Zeit wenn möglich, Binäranalyse wenn nötig, und operationalisieren Sie ihn vor dem ENISA-Meldestichtag im September 2026.