Was ist eine SBOM? Die Software-Stückliste für Firmware-Teams

01Die kurze Antwort

Eine SBOM (Software Bill of Materials, auf Deutsch Software-Stückliste) ist eine maschinenlesbare Liste der Komponenten in einer Software oder Firmware: welche Open-Source-Bibliotheken drinstecken, in welchen Versionen, woher sie kommen und wie sie voneinander abhängen. Wird eine neue Schwachstelle veröffentlicht, beantworten Sie damit die Frage „Welche unserer Produkte enthalten diese Bibliothek, und in welcher Version?“ in wenigen Minuten. Für Produkte mit digitalen Elementen, die auf dem EU-Markt in Verkehr gebracht werden, schreibt der CRA eine SBOM vor.

Am einfachsten stellt man sie sich als Gegenstück zur Stückliste in der Fertigung vor. Der Unterschied: Softwarekomponenten ändern sich mit jedem Release. Eine SBOM ist deshalb kein Dokument, das man einmal schreibt und ablegt. Sie ist ein Build-Ergebnis und entsteht für jede Firmware-Version neu.

02Was gehört in eine SBOM?

Unabhängig vom Format enthält eine brauchbare SBOM für jede Komponente im Wesentlichen dieselben Angaben:

• Name und Version: zum Beispiel openssl und 3.0.13. Ein Eintrag ohne Version findet beim Abgleich entweder gar nichts oder zieht jede Schwachstelle an, die die Bibliothek je hatte.
• Lieferant: wer die Komponente geschrieben oder geliefert hat. Bei Open Source ist das meist das Projekt selbst, bei Closed Source die Firma, von der Sie das SDK bekommen haben.
• Eindeutige Kennungen: eine PURL (pkg:generic/openssl@3.0.13) und eine CPE. Schwachstellendatenbanken finden Komponenten über diese Schlüssel, nicht über den Namen.
• Hashwert: der SHA-256- oder SHA-512-Hash der Datei. Er belegt, dass der Eintrag genau die Datei beschreibt, die tatsächlich im Image liegt.
• Abhängigkeiten: welche Komponente welche andere nutzt. Darüber verfolgen Sie, auf welchem Weg eine Schwachstelle ins Produkt gekommen ist.

Hier ein gekürztes CycloneDX-Beispiel für eine Router-Firmware. Eine echte Datei hat Hunderte Komponenten, der Hashwert ist hier abgekürzt:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": { "bom-ref": "fw", "type": "firmware",
                   "name": "router-fw", "version": "2.4.1" }
  },
  "components": [
    { "bom-ref": "busybox", "type": "application",
      "name": "busybox", "version": "1.36.1",
      "purl": "pkg:generic/busybox@1.36.1" },
    { "bom-ref": "openssl", "type": "library",
      "name": "openssl", "version": "3.0.13",
      "cpe": "cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*",
      "hashes": [{ "alg": "SHA-256", "content": "…" }] }
  ],
  "dependencies": [{ "ref": "fw", "dependsOn": ["busybox", "openssl"] }]
}

metadata.component ist das Produkt selbst, also die Firmware. Der Block dependencies sagt, dass die Firmware von busybox und openssl abhängt. openssl haben wir eine CPE gegeben, busybox eine PURL. In der Praxis lohnt es sich, für jede Komponente beides einzutragen, weil der Abgleich dann mehr Treffer liefert.

03SPDX und CycloneDX

Beide Formate sind ausgereift, und beide erfüllen die Bedingung des CRA, ein „gängiges maschinenlesbares Format“ zu sein. Welches Sie nehmen, entscheiden meist Ihre Kunden oder Ihre Werkzeuge. Konverter zwischen den beiden gibt es.

Oft verrät schon der Dateiname das Format. SPDX-JSON-Dateien enden meist auf *.spdx.json (Microsofts sbom-tool schreibt zum Beispiel manifest.spdx.json), CycloneDX-Dateien heißen typischerweise bom.json, bom.xml oder *.cdx.json.

04Warum SBOMs bei Embedded-Geräten schwierig sind

Bei einer Webanwendung fällt die SBOM praktisch aus der Lock-Datei heraus (package-lock.json, poetry.lock), denn die Abhängigkeiten stehen dort schon. Firmware hat selten eine solche Datei. Und wenn doch, bildet sie nur einen Teil des Images ab.

• Ausgeliefert wird das Build-Ergebnis, nicht der Quellcode. Beim Build kann ein Patch eingespielt, ein Feature abgeschaltet oder ein Paket ganz aus dem Image herausgelassen worden sein. Eine Liste aus dem Quellbaum entfernt sich dadurch von dem, was wirklich im Image steckt. Das Image-Manifest von Yocto oder die Ausgabe von make legal-info in Buildroot ist ein guter Ausgangspunkt, weil beide auflisten, was ins Image gegangen ist.
• Statisch gelinkte Bibliotheken. Ein mbedTLS oder zlib, das statisch in einen Dienst gelinkt ist, liegt nicht als eigene Datei im Dateisystem und taucht in keiner Paketliste auf. Seine Schwachstellen werden trotzdem mit dem Produkt ausgeliefert. Finden lässt es sich nur per Binäranalyse: Versionsstrings, Signaturen bekannter Funktionen.
• RTOS- und SDK-Komponenten. Mikrocontroller-Firmware hat keinen Paketmanager. RTOS-Kernel, TCP/IP-Stack, TLS-Bibliothek und die HAL des Herstellers werden als Quellcode ins Projekt kopiert und zu einem einzigen Binary kompiliert. Die Version überlebt oft nur in einer Header-Datei oder in irgendeiner Commit-Nachricht.
• Geschlossener Code von Zulieferern. Der WLAN-Treiber, der Bluetooth-Stack oder die Modem-Firmware kommen als Binary. Was darin steckt, weiß nur der Zulieferer. Deshalb wandert die Pflicht, eine maschinenlesbare SBOM mitzuliefern, gerade als Klausel in die Einkaufsverträge.

In der Praxis liefert die Kombination zweier Quellen das verlässlichste Ergebnis: die Pakete, die das Build-System kennt, und das, was die Binäranalyse im Image findet. Jede Quelle fängt auf, was die andere übersieht.

05Was der CRA verlangt

Artikel 3 Nummer 39 definiert die Software-Stückliste als „eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“. Die eigentliche Pflicht steht in Anhang I Teil II Nummer 1: Der Hersteller ermittelt und dokumentiert Schwachstellen und Komponenten seiner Produkte, unter anderem durch eine Software-Stückliste „in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“.

• Die SBOM ist Teil der technischen Dokumentation (Anhang VII Nummer 2 Buchstabe b).
• Eine Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern, wenn sie sie braucht, um die Einhaltung von Anhang I zu prüfen (Anhang VII Nummer 8).
• Eine Pflicht zur Veröffentlichung gibt es nicht. Erwägungsgrund 77 sagt ausdrücklich: „Hersteller sollten nicht verpflichtet sein, die Software-Stückliste zu veröffentlichen“. Wenn Sie sie den Nutzern dennoch zugänglich machen, steht in den Informationen für den Nutzer, wo sie zu finden ist (Anhang II Nummer 9).
• Ein bestimmtes Format nennt die Verordnung nicht. Nach Artikel 13 Absatz 24 kann die Kommission Format und Elemente der SBOM per Durchführungsrechtsakt festlegen.
• Die Pflicht gilt ab dem 11. Dezember 2027, zusammen mit dem Rest der Verordnung.

Die BSI TR-03183-2 verlangt mehr

Die Technische Richtlinie BSI TR-03183-2 des Bundesamts für Sicherheit in der Informationstechnik (BSI) geht deutlich über „zumindest die obersten Abhängigkeiten“ hinaus. Version 2.1.0 vom August 2025 legt Folgendes fest:

• Eine neu erzeugte SBOM liegt als JSON oder XML vor, im Format CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1.
• Abhängigkeiten werden entlang jedes Pfads im Lieferumfang rekursiv aufgelöst, mindestens bis zur ersten Komponente außerhalb des Lieferumfangs.
• Zu den Pflichtfeldern gehören Ersteller und Zeitstempel der SBOM sowie für jede Komponente Ersteller, Name, Version, Dateiname, Abhängigkeiten, Distributionslizenzen und der SHA-512-Hashwert der auslieferbaren Datei.

Die TR-03183 ist keine harmonisierte Norm zum CRA. Sie gehört aber zu den wenigen öffentlichen Dokumenten, die den Inhalt einer SBOM so genau beschreiben, und taugt gut als Checkliste, wenn Sie Ihre SBOM-Pipeline entwerfen.

06Die US-Mindestelemente für SBOMs 2026 (CISA)

Am 29. Juli 2026 hat die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) „2026 Minimum Elements for a Software Bill of Materials (SBOM)“ veröffentlicht. Das Dokument ersetzt die Mindestelemente, die die NTIA 2021 veröffentlicht hatte, und entstand mit 17 Partnerorganisationen, darunter NSA und FBI, das deutsche BSI, die französische ANSSI und das niederländische NCSC-NL. Nach eigener Aussage schaffen die Mindestelemente keine neuen Anforderungen; sie präzisieren, wie Organisationen SBOMs erstellen und anfordern sollten.

Die Mindestelemente bestehen aus zwei Gruppen:

• Datenfelder (17): für die SBOM selbst Autor, Signatur des Autors, Name und Version des Datenformats, Erstellungskontext, Zeitstempel, Name und Version des Werkzeugs sowie SBOM-Version; für jede Komponente Name, Version, Hersteller, Kennungen, Hashwert und Hash-Algorithmus, Lizenz und Abhängigkeitsbeziehung.
• Praktiken und Prozesse (6): Aktualisierungen und Korrekturen der SBOM-Daten zulassen, Abdeckung, Verteilung und Bereitstellung, unbekannte Informationen ausdrücklich kennzeichnen, Häufigkeit (eine neue SBOM für jede Version) und maschinenverarbeitbare Daten (heute verbreitet: SPDX und CycloneDX).

Der CRA verweist nicht auf dieses Dokument; das CISA-Dokument nennt seinerseits den CRA als EU-Regelung, die eine Software-Stückliste in der technischen Dokumentation verlangt. Die beiden Ansätze widersprechen sich nicht, verlangen aber nicht dieselbe Tiefe. Der CRA verlangt eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten erfasst. Das CISA-Dokument verlangt alle Komponenten einschließlich transitiver Abhängigkeiten, legt keine Mindesttiefe fest und zählt Hashwert, Lizenz und Signatur des Autors zu den Mindestfeldern. Eine SBOM nach dem CISA-Dokument geht in Abdeckung und Format über das Minimum des CRA hinaus; umgekehrt gilt das nicht immer. Für den EU-Markt maßgeblich bleiben der CRA und ein etwaiger Durchführungsrechtsakt der Kommission nach Artikel 13 Absatz 24.

07SBOM und VEX

Die SBOM beantwortet die Frage „Was steckt drin?“. Gleichen Sie sie mit einer Schwachstellendatenbank ab (OSV, NVD), bekommen Sie eine Rohliste: openssl 3.0.13 ist enthalten, und diese CVEs betreffen genau diese Version. Nicht jeder Eintrag auf der Liste betrifft Ihr Produkt. Der verwundbare Code ist vielleicht gar nicht mitkompiliert oder wird nie aufgerufen.

VEX (Vulnerability Exploitability eXchange) beantwortet die zweite Frage: Sind wir betroffen? Jede Schwachstelle bekommt einen Status: betroffen, nicht betroffen (mit Begründung), behoben oder in Untersuchung. Verbreitete Wege, das zu veröffentlichen, sind CSAF 2.0 und OpenVEX. CycloneDX kann VEX auch in eigenen Dokumenten mitführen.

Die beiden gehören zusammen. Die SBOM wird für jedes Release neu erzeugt, die VEX-Angaben werden aktualisiert, sobald neue Schwachstellen veröffentlicht werden. Ein Team ohne SBOM kann kein VEX schreiben. Und ein Team ohne VEX beantwortet am Ende jeden Alarm aus dem Scanner jedes Kunden einzeln.

08Häufige Fehler

• Die SBOM einmal erzeugen und ablegen. Jede Firmware-Version braucht ihre eigene.
• Die Liste aus dem Quellbaum für die Wahrheit über das Image halten.
• Versionsfelder leer lassen.
• PURL und CPE weglassen. Ein Abgleich über ähnliche Namen erzeugt Fehlalarme.
• Statisch gelinkte Bibliotheken und Zulieferer-Binaries übersehen.
• Die SBOM erzeugen und danach nicht überwachen. Die Komponenten müssen während des gesamten Unterstützungszeitraums auf neue Schwachstellen beobachtet werden.
• Die rohe Schwachstellenliste unverändert an Kunden schicken. Ohne VEX ist sie größtenteils Rauschen.

09Wo Sie anfangen

Wenn Sie Lock-Dateien, ein Yocto-Manifest oder eine Buildroot-manifest.csv haben, macht unser kostenloser SBOM-Scanner daraus eine CycloneDX- oder SPDX-Datei und prüft die Komponenten gegen OSV.dev. Die Dateien werden in Ihrem Browser gelesen und verlassen Ihren Rechner nicht. Wenn Sie die SBOM-Erzeugung direkt aus dem Firmware-Image, VEX und laufende Überwachung an Ihrem eigenen Image ausprobieren möchten, sehen Sie sich unser Pilotprogramm an.

Wo die SBOM zwischen den übrigen CRA-Pflichten steht, zeigt der CRA-Leitfaden. Was speziell für Router, Modems und Netzwerkgeräte gilt, finden Sie unter Netzwerk- und Telekommunikationsgeräte.

10Häufige Fragen