Software-Lieferkette
SBOM: was eine Software-Stückliste ist und wie Sie eine erstellen
Eine SBOM (Software Bill of Materials, in der Verordnung Software-Stückliste) ist eine formale, maschinenlesbare Aufzeichnung der Komponenten einer Software und ihrer Beziehungen zueinander. Der Cyber Resilience Act verpflichtet Hersteller, eine SBOM zu erstellen, die mindestens die obersten Abhängigkeiten abdeckt, in einem gängigen Format wie CycloneDX oder SPDX.
Free-Tarif, keine Kreditkarte erforderlich.
Was ist eine SBOM?
Stellen Sie sie sich als Zutatenliste eines Produkts vor. Für jede Komponente erfasst sie einen Namen, eine Version und idealerweise eine eindeutige Kennung wie eine Package-URL, dazu den Lieferanten und die Beziehungen zwischen den Komponenten: welche Bibliothek welche andere nach sich zieht. Der CRA definiert sie als formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts enthalten sind.
Eine SBOM sagt nicht, ob eine Komponente verwundbar ist. Sie ist die Bestandsaufnahme, die diese Frage beantwortbar macht, heute und jedes Mal, wenn eine neue Schwachstelle veröffentlicht wird.
Ist eine SBOM Pflicht?
Für Hersteller von Produkten im Anwendungsbereich des Cyber Resilience Act: ja. Anhang I Teil II verpflichtet sie, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch Erstellung einer SBOM in einem gängigen, maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten abdeckt. Die SBOM gehört in die technische Dokumentation und muss einer Marktüberwachungsbehörde auf deren begründetes Verlangen vorgelegt werden; eine Veröffentlichung verlangt die Verordnung nicht.
Die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen. Bis dahin sind CycloneDX und SPDX die Formate, die die meisten Tools erzeugen und akzeptieren.
CycloneDX vs. SPDX
Beide sind offene Standards und beide werden breit unterstützt. Die Wahl hängt meist von den Tools ab, die Ihre Kunden und Lieferanten bereits nutzen; viele Teams führen beide.
| CycloneDX | SPDX | |
|---|---|---|
| Gepflegt von | OWASP und Ecma International (ECMA-424) | Linux Foundation; veröffentlicht als ISO/IEC 5962:2021 |
| Ursprung | Anwendungssicherheit und Lieferkettenrisiken | Lizenz-Compliance |
| Serialisierungen | JSON, XML, Protocol Buffers | JSON, Tag-Value, RDF, YAML und weitere |
| Schwachstellendaten | Integrierte VEX-Unterstützung | Separate VEX-Dokumente sind üblich |
Wie Sie eine SBOM erstellen
Die genaueste SBOM entsteht aus dem, was Sie tatsächlich ausliefern. Bei Quellcode sind das die Lockfiles und Manifeste, die Ihr Build auflöst; bei Firmware- und Container-Images sind es die Dateien im Image, weil Build-Tools Pakete übersehen können, die erst später in der Pipeline hinzukommen.
- Erzeugen Sie sie in der Build-Pipeline, für jedes Release, nicht von Hand.
- Scannen Sie neben dem Quellcode auch das fertige Artefakt, einschließlich Firmware- und Container-Images.
- Erfassen Sie exakte Versionen und Package-URLs, keine Versionsbereiche.
- Bewahren Sie die SBOM jeder noch unterstützten Version auf; Sie brauchen sie, wenn eine neue Schwachstelle auftaucht.
- Prüfen Sie gespeicherte SBOMs erneut gegen neue Schwachstellendaten, statt alte Releases neu zu bauen.
Was Sie mit einer vorhandenen SBOM tun sollten
Ihren Wert zeigt eine SBOM, sobald eine neue Schwachstelle veröffentlicht wird. Mit einer Bestandsaufnahme pro Release dauert die Frage „Welche unserer Produkte enthalten diese Komponente?“ Minuten statt Tage. Diese Geschwindigkeit zählt nach Artikel 14 des CRA, wo eine aktiv ausgenutzte Schwachstelle eine 24-Stunden-Meldefrist auslöst.
Ergänzen Sie sie um VEX-Aussagen (Vulnerability Exploitability eXchange), um festzuhalten, welche aufgeführten Schwachstellen das Produkt nicht betreffen und warum, damit Kunden und Behörden neben der Bestandsaufnahme auch die Entscheidung sehen.
Heute in KROMSE verfügbar
KROMSE erstellt und liest SBOMs schon heute.
- Jeder Scan eines Repositorys, Container-Images oder Linux-basierten Firmware-Images erzeugt eine CycloneDX-JSON- und eine SPDX-JSON-SBOM zum Download.
- Laden Sie SBOMs in CycloneDX (JSON 1.2 bis 1.7 oder XML) oder SPDX 2.2 und 2.3 (JSON oder Tag-Value) hoch, dazu Build-Manifeste aus Yocto und Buildroot; jeder Upload wird automatisch mit OSV.dev abgeglichen.
- Übermitteln Sie SBOMs aus der CI mit einem API-Token des Arbeitsbereichs; Snippets gibt es für GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, Yocto, Buildroot, Zephyr und ESP-IDF.
- VEX-Export als CycloneDX 1.6 VEX und OpenVEX, wobei jede importierte VEX-Aussage von einer Person akzeptiert wird.
- In kostenpflichtigen Tarifen wird die jeweils neueste SBOM jedes Produkts alle sechs Stunden erneut mit OSV abgeglichen.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q1 2027Hardwarekomponenten. KROMSE wird die Hardwarekomponenten Ihres Produkts mit veröffentlichten Sicherheitshinweisen zu Hardware abgleichen.
- Geplant · Q1 2027Sicherheit von KI-Agenten und -Modellen. KROMSE wird eine KI-Stückliste (AI Bill of Materials) erstellen, prüfen, welche Tools und Berechtigungen Ihre Agenten nutzen können, und unsichere Modelldateien erkennen.
Häufige Fragen
Wofür steht SBOM?
Für Software Bill of Materials, auf Deutsch Software-Stückliste: eine formale, maschinenlesbare Liste der Komponenten einer Software mit ihren Versionen, Lieferanten und Beziehungen. Sie funktioniert wie eine Zutatenliste und ist der Ausgangspunkt, um herauszufinden, ob ein Produkt eine verwundbare Komponente enthält.
Verlangt der Cyber Resilience Act eine SBOM?
Ja. Anhang I Teil II verpflichtet Hersteller von Produkten mit digitalen Elementen, eine SBOM in einem gängigen, maschinenlesbaren Format zu erstellen, die mindestens die obersten Abhängigkeiten abdeckt. Sie ist Teil der technischen Dokumentation und wird Marktüberwachungsbehörden auf begründetes Verlangen vorgelegt.
Welches SBOM-Format sollte ich verwenden?
CycloneDX und SPDX sind beide gängig, maschinenlesbar und breit unterstützt. Wählen Sie das Format, das Ihre Kunden und Tools erwarten, oder erzeugen Sie beide. Konsistenz über alle Releases hinweg ist wichtiger als die Wahl des Formats.
Muss ich meine SBOM veröffentlichen?
Der CRA verpflichtet Hersteller nicht, die SBOM öffentlich zu machen. Sie muss Teil der technischen Dokumentation sein und einer Marktüberwachungsbehörde vorgelegt werden, die sie anfordert. Viele Unternehmen teilen SBOMs auf vertraglicher Grundlage mit ihren Kunden.
Kann ich eine SBOM für Firmware erstellen?
Ja. Bei Linux-basierter Firmware ist der verlässliche Weg, das Image zu entpacken und die darin enthaltenen Pakete und Binärdateien aufzulisten, statt sich nur auf Build-Dateien zu verlassen. KROMSE tut das heute für Linux-basierte Firmware-Images; Bare-Metal- und RTOS-Images stehen auf der Roadmap.