Firmware-SBOM erstellen: 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 zwei 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 genutzt wird.

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.

Anhang I, Teil II der CRA verpflichtet Hersteller:

"(1) Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen;"

Für Firmware bedeutet "oberste Abhängigkeiten" jedes OS-Paket, jede gemeinsam genutzte Bibliothek, jeden Bootloader und jedes Kernel-Modul im Image, nicht nur das, was ein Paketmanager meldet.

Den vollständigen regulatorischen Kontext finden Sie unter SBOM-Anforderungen gemäß CRA.

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 ist die Generierung eines Firmware-SBOM schwieriger als ein Standard-Software-SBOM?

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)

Das OpenEmbedded-Build-System erzeugt SPDX-SBOM-Daten standardmäßig, indem es create-spdx über INHERIT_DISTRO erbt. Nach einem normalen Image-Build liegt die wichtigste SPDX-JSON-Datei im Deploy-Verzeichnis des Images:

# Nach einem normalen Yocto-Image-Build
ls tmp/deploy/images/MACHINE/
# IMAGE-MACHINE.spdx.json         ← SPDX-Hauptdokument
# SBOM-Metadaten der Rezepte sind für Rezepte im Image enthalten

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:

# Zu local.conf hinzufügen
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

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

Buildroot: make legal-info + CycloneDX-Generator

# Schritt 1: Komponentenmanifest erzeugen
make legal-info
# Ausgabe: output/legal-info/manifest.csv

# Schritt 2: In CycloneDX-SBOM umwandeln
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: Beim Build auf CVEs scannen
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.

Zephyr RTOS: west spdx

Zephyr erzeugt SBOMs nativ über den Befehl west spdx. Standardmäßig entstehen SPDX-2.3-Dokumente im Tag-Value-Format:

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

Die Ausgabe liegt in build/spdx/ und umfasst app.spdx, zephyr.spdx, build.spdx und modules-deps.spdx. Drittanbieter-Blobs oder Out-of-Tree-Bibliotheken, die nicht von den Build-Metadaten erfasst werden, fehlen. Dokumentieren Sie diese Lücken oder fügen Sie sie manuell als externe Komponenten hinzu.

Für FreeRTOS und Bare-Metal-RTOS-Plattformen ohne natives SBOM-Tooling scannen Sie das kompilierte Binary mit cve-bin-tool. Erfassen Sie die RTOS-Kernelversion und enthaltene Middleware manuell als CycloneDX-Komponenten.

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 ist das Standard-Open-Source-Tool zum Entpacken von Firmware:

# binwalk installieren
pip install binwalk

# Alle eingebetteten Dateisysteme extrahieren
binwalk -eM firmware.bin

# Prüfen, was extrahiert wurde
ls _firmware.bin.extracted/

# Vor dem Fortfahren auf verschlüsselte Partitionen prüfen
binwalk -E firmware.bin
# Hohe Entropie (über 0.9) weist auf verschlüsselte Inhalte hin

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

# Paketmanager-Datenbanken prüfen
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

# Syft auf dem extrahierten Dateisystem ausführen
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

# Intels cve-bin-tool installieren
pip install cve-bin-tool

# Extrahiertes Binärverzeichnis scannen
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:

# EMBA klonen und einrichten
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# EMBA mit SBOM-Ausgabe ausführen
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. BSI TR-03183-2 v2.1.0, die deutsche BSI-Richtlinie für SBOMs unter der CRA, empfiehlt CycloneDX 1.6+ oder SPDX 3.0.1+ und wird von Auditoren und notifizierten Stellen am häufigsten herangezogen.

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.

Fünf 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. SBOM signieren. Signieren Sie die erzeugte Datei mit cosign von Sigstore, bevor Sie sie speichern oder teilen:

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

   Speichern Sie das Bundle neben dem SBOM. Kunden und Behörden können es mit cosign verify-blob prüfen. Die CRA verlangt das heute nicht, aber Supply-Chain-Sicherheitsframeworks wie SLSA und in-toto erwarten es.

4. 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.

5. 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

□ 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