SBOM Management — Software Bill of Materials unter dem Cyber Resilience Act

Eine Software Bill of Materials ist das, was auf der Verpackung einer Lebensmittelpackung die Zutatenliste ist: eine strukturierte, maschinenlesbare Aufstellung aller Komponenten, aus denen eine Software zusammengesetzt ist, inklusive ihrer Versionen und Abhängigkeiten. Das Konzept stammt aus der Reaktion auf den Log4Shell-Vorfall Ende 2021 und wurde in den USA durch Executive Order 14028 erstmals verbindlich gemacht. Mit dem Cyber Resilience Act zieht die EU nach — und geht in mancher Hinsicht weiter.

Anhang I Teil 2 des CRA verlangt, dass Hersteller „die in den Produkten mit digitalen Elementen enthaltenen Komponenten identifizieren und dokumentieren, einschließlich durch die Erstellung einer Software Bill of Materials in einem gängigen und maschinenlesbaren Format, das zumindest die Top-Level-Abhängigkeiten der Produkte abdeckt.“ Die Anforderung klingt klein, entfaltet aber erhebliche operative Wirkung: Eine SBOM ist kein Excel-Sheet, sondern ein Artefakt, das bei jedem Build neu erzeugt, versioniert, signiert und zusammen mit dem Produkt aufbewahrt werden muss.

Was in eine SBOM gehört

Die europäische Kommission hat im Entwurf des Durchführungsrechtsakts die Mindestinhalte präzisiert: Jede Komponente muss mit einem Bezeichner (Name und Version), einem Lieferanten (Supplier), einem eindeutigen Package-URL (purl) oder CPE, einem Hashwert (z. B. SHA-256) und dem Lizenztyp beschrieben werden. Zusätzlich müssen die Relationen zwischen Komponenten abgebildet sein — welche Komponente von welcher abhängt.

Der CRA fordert zwingend nur die Top-Level-Abhängigkeiten. In der Praxis genügt das aber nicht: Wenn in einer transitiven Abhängigkeit (also der Abhängigkeit einer Abhängigkeit) eine kritische Schwachstelle entsteht, muss der Hersteller trotzdem innerhalb von 24 Stunden reagieren. Ohne vollständige transitive SBOM ist diese Reaktionszeit schwer einzuhalten.

Eine gute SBOM-Strategie lagert die Tiefe deshalb ins eigene Werkzeug aus: Die ausgelieferte SBOM deckt das Pflichtminimum, intern wird ein vollständiger Abhängigkeitsgraph gepflegt, auf den Vulnerability-Monitoring-Tools zugreifen.

CycloneDX oder SPDX — die Formatfrage

Die beiden großen SBOM-Formate sind CycloneDX und SPDX. CycloneDX wurde von der OWASP Foundation entwickelt, ist bewusst schlank gehalten und deckt neben reiner Abhängigkeitsdokumentation auch Vulnerability Disclosure (VEX), Services und Machine-Learning-Modelle ab. SPDX ist älter, wurde von der Linux Foundation vorangetrieben und ist seit 2021 als ISO/IEC 5962 standardisiert. Es hat seine Stärke in der detaillierten Lizenz- und Urheberrechtsdokumentation.

Für Hersteller, die den CRA erfüllen müssen, sind beide Formate zulässig, solange sie „gängig und maschinenlesbar“ sind. Die Entscheidung fällt daher nach Toolchain: Wer bereits Syft, Trivy oder cdxgen einsetzt, landet meist bei CycloneDX. Wer SPDX aus historischen Gründen pflegt (z. B. Yocto-basierte Embedded-Systeme), bleibt bei SPDX.

Ein Wechsel zwischen den Formaten ist möglich: Tools wie cyclonedx-spdx-cli konvertieren zwischen beiden, allerdings nicht verlustfrei. Wer neu anfängt, sollte CycloneDX bevorzugen, weil die VEX-Integration für das CRA-Schwachstellenhandling deutlich eleganter ist.

SBOM in CI/CD produktiv einbauen

Eine SBOM, die manuell gepflegt wird, ist praktisch wertlos. Die Grundregel lautet: Die SBOM wird bei jedem Build automatisch erzeugt, zusammen mit dem Release-Artefakt signiert, im Artefakt-Repository abgelegt und bei jedem Release dem Produkt beigefügt (z. B. als detachable file im Installer oder als OCI-Artefakt im Container-Registry).

Praxisbewährte Toolketten: Für Container verwenden viele Teams Syft zur Erzeugung und Grype oder Trivy zum kontinuierlichen Schwachstellen-Scan. Für Java/Gradle/Maven existieren die offiziellen CycloneDX-Plugins, für Node.js cdxgen, für Python cyclonedx-python. Die erzeugte SBOM wird anschließend mit cosign signiert und in das gleiche Registry wie das Container-Image gepusht.

Für die CRA-Pflicht reicht das Erzeugen allein nicht. Die SBOM muss zusätzlich einem Asset zugeordnet werden, das über die gesamte Unterstützungszeit des Produkts (mindestens fünf Jahre) aufbewahrt wird. Das ist eine Aufbewahrungspflicht, die typischerweise in das Release-Management integriert werden muss, nicht ins CI-System.

Tools für SBOM Management — eine nüchterne Einordnung

Der Markt für SBOM-Tools ist geteilt. Auf der einen Seite stehen die offenen Generatoren wie Syft, cdxgen, Trivy und die CycloneDX/SPDX-Referenzimplementierungen — diese sind kostenlos, gut gepflegt und reichen für viele Mittelständler als Basis aus. Auf der anderen Seite positionieren sich kommerzielle SBOM-Management-Plattformen, die neben der Erzeugung auch zentrale Verwaltung, Versionsvergleich, Vulnerability-Monitoring und automatische Benachrichtigungen bieten. Dazu zählen unter anderem Snyk, Sonatype Lifecycle, JFrog Xray, FOSSA und Anchore Enterprise.

Die wichtigste Frage ist nicht „welches Tool ist das beste?“, sondern „wie bekomme ich aus einer Schwachstellenmeldung in einer meiner Komponenten innerhalb von 24 Stunden eine belastbare Antwort an das CSIRT?“. Teams, die diese Frage sauber beantworten können, haben den Kern des SBOM-Managements verstanden. Alles andere sind Werkzeugdetails.