SBOM: Die Software-Stückliste, die jetzt Pflicht wird

Eine SBOM ist eine maschinenlesbare Stückliste aller Komponenten einer Software: eigene Module, Open-Source-Bibliotheken, zugekaufte Komponenten und deren Abhängigkeiten, jeweils mit Version, Lizenz und Herkunft. Sie macht die Software-Lieferkette transparent und beantwortet im Ernstfall in Minuten die Frage, welche Produkte eine verwundbare Komponente enthalten. Gängige Formate sind CycloneDX und SPDX.

Ja. Der CRA (Verordnung (EU) 2024/2847) verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, mindestens die obersten Abhängigkeitsebenen als SBOM, und sie der Marktüberwachung auf Verlangen vorzulegen. In Deutschland ist das BSI zuständig; die Anforderungen konkretisiert die Technische Richtlinie TR‑03183‑2. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten ab dem 11. September 2026, die volle CRA-Anwendbarkeit ab dem 11. Dezember 2027.

CycloneDX stammt von der OWASP-Community und ist auf Sicherheitsanwendungen ausgelegt: Schwachstellenabgleich, VEX-Integration, DevSecOps-Toolchains. SPDX kommt von der Linux Foundation, ist als ISO/IEC 5962 normiert und historisch stark in der Lizenz-Compliance. Beide sind maschinenlesbar und vom BSI akzeptiert. In der Praxis entscheidet oft das Ökosystem: Wer Dependency-Track und Security-Tools nutzt, fährt meist mit CycloneDX besser; wer primär Lizenzpflichten managt, mit SPDX. Viele Werkzeuge exportieren beide Formate.

Als Minimum haben sich die NTIA Minimum Elements etabliert: Komponentenname, Version, Lieferant, eindeutige Identifikatoren (etwa purl oder CPE), Abhängigkeitsbeziehungen, Ersteller der SBOM und Zeitstempel. Die BSI TR‑03183‑2 ergänzt unter anderem Angaben zu Lizenzen und Hashwerten. Wichtig ist die eindeutige Identifizierbarkeit jeder Komponente, sonst scheitert der automatische Abgleich mit Schwachstellendatenbanken.

Etablierte Open-Source-Werkzeuge sind Syft (Anchore) und Trivy (Aqua Security), beide erzeugen CycloneDX und SPDX aus Quellcode, Artefakten und Container-Images. Microsoft stellt das SBOM Tool bereit, GitLab und GitHub generieren SBOMs direkt in der Pipeline. Für die Verwaltung und den CVE-Abgleich hat sich Dependency-Track (OWASP) etabliert. Die Toolfrage ist selten der Engpass; entscheidend ist die automatisierte Erzeugung bei jedem Release.

Eine CycloneDX-SBOM im JSON-Format enthält einen Metadatenblock (Produkt, Version, Ersteller, Zeitstempel) und eine Komponentenliste. Ein Eintrag sieht vereinfacht so aus: name 'log4j-core', version '2.17.1', purl 'pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1', Lizenz 'Apache-2.0', Hash des Artefakts. Dazu kommen die Abhängigkeitsbeziehungen zwischen den Komponenten. Bei typischen Anwendungen kommen schnell mehrere hundert bis tausende Einträge zusammen, weshalb manuelle Pflege ausscheidet.

VEX (Vulnerability Exploitability eXchange) ist das Gegenstück zur SBOM: ein maschinenlesbares Statement des Herstellers, ob ein Produkt von einer bekannten Schwachstelle tatsächlich betroffen ist. Ohne VEX erzeugt der SBOM-Abgleich mit CVE-Datenbanken viele Fehlalarme, weil eine enthaltene Komponente nicht automatisch ausnutzbar ist. Mit VEX dokumentieren Sie begründet 'nicht betroffen' und konzentrieren die Behebung auf reale Risiken.

Ja. Container-Images sind sogar der häufigste Anwendungsfall: Werkzeuge wie Syft und Trivy scannen Images inklusive Betriebssystempaketen. Für Firmware und eingebettete Systeme ist die Erzeugung anspruchsvoller (Binäranalyse, Yocto- und Buildroot-Integration), aber gerade dort greift der CRA, weil Produkte mit digitalen Elementen im Fokus stehen. Hersteller vernetzter Geräte sollten früh beginnen.

NIS2 verlangt Sicherheit in der Lieferkette: Betroffene Unternehmen müssen die Risiken ihrer Zulieferer und Dienstleister steuern. Eine SBOM-Anforderung an Softwarelieferanten ist dafür das praktischste Instrument, denn ohne Komponententransparenz lässt sich Lieferkettenrisiko nicht bewerten. Wer als Zulieferer großer Unternehmen auftritt, wird SBOMs zunehmend vertraglich zusichern müssen, unabhängig von der eigenen CRA-Betroffenheit.

Bewährt hat sich eine geteilte Verantwortung: Engineering erzeugt SBOMs automatisiert im Build, Produktsicherheit oder PSIRT verwaltet sie zentral und verantwortet den Schwachstellenabgleich, Compliance nutzt sie für CRA-Dokumentation und Kundennachweise, der Einkauf fordert sie von Lieferanten ein. Ohne benannten Owner versanden SBOM-Initiativen erfahrungsgemäß nach dem ersten Proof of Concept.

Die Werkzeuge selbst sind überwiegend Open Source und kostenfrei. Der Aufwand liegt in der Integration: Pipeline-Anpassung, zentrale Verwaltung, VEX-Prozess und Lieferantensteuerung. Ein Readiness-Assessment mit Roadmap ist in ein bis zwei Wochen machbar; die Umsetzung hängt von der Anzahl der Produkte und Pipelines ab. Wir kalkulieren transparent nach Scope und beginnen mit den Produkten, die zuerst unter die CRA-Fristen fallen.

Die SBOM ist die Inventargrundlage des Schwachstellenmanagements für Software-Komponenten: Der kontinuierliche Abgleich der SBOM gegen CVE-Feeds zeigt, welche Produkte von neuen Schwachstellen betroffen sind, VEX bewertet die tatsächliche Ausnutzbarkeit, und die Behebung läuft über Ihre Patch- und Release-Prozesse. Der CRA verlangt genau diese Kette; ab dem 11. September 2026 inklusive Meldung aktiv ausgenutzter Schwachstellen an ENISA binnen 24 Stunden.