SBOMs im regulatorischen Rampenlicht: CRA und DORA schaffen eine neue Realität

Die digitale Welt basiert auf Software – und diese ist selten vollständig selbst entwickelt. Moderne Softwareprodukte setzen sich aus einer Vielzahl von Komponenten zusammen, viele davon aus Drittquellen, insbesondere sind es oft frei verfügbare Open Source Abhängigkeiten. In diesem komplexen Geflecht den Überblick zu behalten, ist herausfordernd – aber notwendig.

Der Cyber Resilience Act (CRA) verlangt explizit eine Software Bill of Materials (SBOM), um Transparenz über eingesetzte Komponenten sicherzustellen (Anhang 1 Teil II (1)). Der Digital Operational Resilience Act (DORA) fordert, dass Mechanismen etabliert werden, um „potenzielle einzelne wesentliche Schwachstellen zu ermitteln“ (Art. 10), und darüber hinaus die Präsenz von „Kapazitäten und Personal, um Informationen über Schwachstellen und Cyberbedrohungen […] zu sammeln und […] zu untersuchen (Art. 13). Auch hier kommt man bei der Individual-Software-Entwicklung auf das Thema SBOMs.

Was bislang eher optional oder bestenfalls „Best Practice“ war, wird durch die beiden Verordnungen zur gesetzlichen Pflicht. Unternehmen tun gut daran das Thema ernst zu nehmen. Hersteller gewinnen mit SBOMs eine vollständige Auflistung von Softwarekomponenten, einschließlich Third-Party- und Open-Source-Abhängigkeiten.

SBOMs: Formate, Inhalte und Standards

Eine Software Bill of Materials (SBOM) beschreibt die externen Abhängigkeiten einer Software. Typischerweise enthält eine SBOM Angaben zur eindeutigen Identifikation einer Komponente (z. B. Gruppen- und Paketname), zur verwendeten Version, zu Lizenzinformationen, kryptografischen Hashwerten sowie zu weiterführenden Referenzen.

Zur Beschreibung dieser Informationen haben sich zwei standardisierte Formate etabliert. Das SPDX-Format (Software Package Data Exchange) wurde ursprünglich für die Lizenzdokumentation entwickelt, wird inzwischen jedoch auch für sicherheitsbezogene Anwendungsfälle verwendet. CycloneDX hingegen wurde von Anfang an mit Fokus auf sicherheitsrelevante Analysen konzipiert und wird unter anderem durch das OWASP-Projekt aktiv gepflegt und weiterentwickelt.

Für die Erstellung einer SBOM existieren im Wesentlichen zwei technische Ansätze: build-basiert und scan-basiert. Beim build-basierten Verfahren wird die SBOM direkt im Rahmen des Build-Prozesses erzeugt – etwa mithilfe von Plugins wie cyclonedx-maven-plugin, cyclonedx-gradle-plugin, cyclonedx-node-npm oder npm-sbom. Diese Methode liefert in der Regel sehr präzise Informationen zu den deklarierten Abhängigkeiten einschließlich der transitiven Abhängigkeiten. Sie bezieht sich jedoch ausschließlich auf das generierte Build-Artefakt.

Dem gegenüber steht der scan-basierte Ansatz, bei dem Werkzeuge wie Syft, Trivy, FOSSA oder Snyk nachträglich Container-Images, Dateisysteme oder Artefakte scannen und analysieren. Diese Methode kann auch eingebettete oder nicht deklarierte Abhängigkeiten identifizieren, ist aber möglicherweise weniger vollständig und kontextbezogen, insbesondere wenn Metadaten fehlen oder statische Analysen an ihre Grenzen stoßen.

In vielen Fällen reicht ein rein build-basierter Ansatz nicht aus, da ausgelieferte Softwareprodukte in der Praxis häufig nicht nur aus dem Build-Artefakt bestehen, sondern zusätzlich in ein Laufzeitartefakt – typischerweise ein Container-Image – eingebettet werden. Es empfiehlt sich daher, auch die im Container enthaltenen Komponenten so weit wie möglich zu erfassen. Dabei gilt: je schlanker das Image, desto überschaubarer die Analyse und desto geringer die potenzielle Angriffsfläche.

Um den Nutzen von SBOMs im Betriebs- und Sicherheitskontext zu maximieren, sollten sie automatisiert und regelmäßig im Rahmen von CI/CD-Pipelines erzeugt werden. Eine manuelle oder einmalige Erstellung reicht nicht aus, um regulatorische Anforderungen oder Sicherheitsziele zuverlässig zu erfüllen.

SBOMs als Grundlage zur Risikobewertung

Eine aktuelle und vollständige SBOM ermöglicht es, die verwendeten Softwarekomponenten systematisch auf bekannte Schwachstellen zu prüfen. Dafür erfolgt ein Abgleich mit öffentlich zugänglichen Schwachstellendatenbanken wie der National Vulnerability Database (NVD) oder CVE.org, um potenziell betroffene Komponenten zu identifizieren. Sie liefern neben der Information, ob eine Schwachstelle bekannt ist, Metriken wie das Common Vulnerability Scoring System (CVSS) und das Exploit Prediction Scoring System (EPSS) und somit Hinweise zur Kritikalität und zur Wahrscheinlichkeit einer tatsächlichen Ausnutzung.

Entscheidend ist jedoch nicht allein das Vorhandensein einer Schwachstelle, sondern ihr Kontext innerhalb der konkreten Softwareanwendung. So ist beispielsweise zu bewerten, ob eine betroffene Bibliothek bzw. die jeweilige Schachstelle tatsächlich zur Laufzeit genutzt wird, indem die relevanten Funktionen über spezifische Call-Paths erreichbar sind. Eine reine Listen-basierte Betrachtung reicht daher nicht aus – für eine belastbare Risikoeinschätzung muss der Bezug zur realen Nutzung innerhalb der eigenen Systemarchitektur berücksichtigt werden.

Fazit & Empfehlungen

SBOMs leisten einen wichtigen Beitrag zur strukturierten und sicheren Softwareentwicklung. Sie schaffen Transparenz über eingesetzte Komponenten, unterstützen die Einhaltung regulatorischer Vorgaben und bilden die Grundlage für eine fundierte Bewertung sicherheitsrelevanter Risiken in der Lieferkette.

Für eine nachhaltige Wirksamkeit sollten SBOMs frühzeitig im Entwicklungsprozess berücksichtigt und automatisiert erzeugt werden. Darüber hinaus empfiehlt sich ihre Einbindung in regelmäßige Prüf- und Analyseprozesse, beispielsweise im Rahmen von Schwachstellenbewertungen. Dabei ist der Einsatz spezialisierter Werkzeuge sinnvoll, um Abhängigkeiten effizient zu analysieren und auf identifizierte Risiken angemessen zu reagieren.

Gleichzeitig gilt es, die Grenzen einer SBOM realistisch einzuschätzen: Sie liefert Informationen zu verwendeten Fremdkomponenten, nicht jedoch zum selbst entwickelten Anwendungscode. Die kontinuierliche Qualitätssicherung und Sicherheitsprüfung des Eigenanteils bleibt daher eine ebenso zentrale Säule innerhalb eines umfassenden Sicherheitskonzepts.

CRA: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R2847
Digital Operational Resilience Act: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022R2554
CycloneDX: https://cyclonedx.org/
Maven cyclonedx: https://github.com/CycloneDX/cyclonedx-maven-plugin
Gradle cyclonedx: https://github.com/CycloneDX/cyclonedx-gradle-plugin
NPM cyclonedx: https://github.com/CycloneDX/cyclonedx-node-npm
NPM SBOM: https://docs.npmjs.com/cli/v10/commands/npm-sbom
SPDX: https://spdx.github.io/spdx-spec
Syft: https://github.com/anchore/syft
Trivy: https://trivy.dev/
Fossa: https://fossa.com/
Snyk: https://snyk.io/de/
NVD: https://nvd.nist.gov/
CVSS: https://de.wikipedia.org/wiki/CVSS
EPSS: https://www.first.org/epss/