SBOM (Software Bill of Materials)
Eine SBOM (Software Bill of Materials) ist die maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts, inklusive Open-Source-Bibliotheken. Der EU Cyber Resilience Act verlangt sie als Teil der technischen Dokumentation — gängige Formate sind SPDX und CycloneDX. Wie die Zutatenliste auf einer Lebensmittelverpackung macht die SBOM transparent, was in einer Software tatsächlich steckt.
Was steht in einer SBOM?
Eine SBOM inventarisiert die Bestandteile einer Software: eigene Module, zugekaufte Komponenten und Open-Source-Bibliotheken samt ihrer transitiven Abhängigkeiten. Zu jeder Komponente gehören typischerweise Name, Version, Hersteller bzw. Herkunft, Lizenzinformationen und eindeutige Identifikatoren. Erst diese Detailtiefe erlaubt es, eine neu bekannt gewordene Schwachstelle (CVE) automatisiert gegen den eigenen Produktbestand abzugleichen.
Formate: SPDX und CycloneDX
Damit SBOMs werkzeugübergreifend verarbeitet werden können, haben sich zwei maschinenlesbare Formate etabliert:
| Format | Herkunft | Besonderheit |
|---|---|---|
| SPDX | Linux Foundation | Als ISO/IEC 5962 international standardisiert, historisch stark im Lizenz-Compliance-Umfeld |
| CycloneDX | OWASP Foundation | Auf Security-Anwendungsfälle ausgelegt, verbreitet in Vulnerability-Management-Werkzeugketten |
Beide Formate erfüllen den Zweck einer maschinenlesbaren Stückliste — wichtiger als die Formatwahl ist, dass die SBOM automatisiert im Build-Prozess erzeugt wird und nicht von Hand gepflegt werden muss.
Die SBOM im Cyber Resilience Act
Der CRA macht die SBOM zur Herstellerpflicht: Anhang I Teil II verlangt sie als Teil der Anforderungen an die Schwachstellenbehandlung, und wie die übrige technische Dokumentation ist sie mindestens zehn Jahre nach Inverkehrbringen aufzubewahren. Ihre eigentliche Bedeutung zeigt sich aber bei den Meldepflichten, die ab dem 11. September 2026 gelten: Ob ein neues CVE in einer Drittkomponente das eigene Produkt betrifft, lässt sich nur mit sauberen Stücklisten beantworten. Ohne maschinenlesbares Wissen, welche Komponente in welcher Produktversion steckt, wird schon die 72-Stunden-Meldung zur Recherchearbeit.
SBOM in der Praxis: Ein lebendes Dokument, kein Einmal-Export
Eine SBOM, die einmal beim Release erzeugt und dann abgelegt wird, verliert mit jedem Update ihren Wert. In der Praxis bewährt sich die automatische Generierung in der CI/CD-Pipeline, sodass jede ausgelieferte Produktversion eine aktuelle Stückliste hat. Der zweite Schritt ist der kontinuierliche Abgleich der SBOM-Komponenten gegen neue Schwachstellenmeldungen — erst diese Verbindung aus Stückliste und Vulnerability-Triage macht aus der Dokumentationspflicht ein funktionierendes Schwachstellenmanagement.