Software Bill of Materials

Eine Software Bill of Materials (SBOM) ist eine strukturierte, maschinenlesbare Inventarliste, die sämtliche Komponenten, Bibliotheken und Abhängigkeiten eines Softwareprodukts dokumentiert. Das Konzept folgt dem Prinzip der Stückliste aus der Fertigungsindustrie: So wie ein Hersteller wissen muss, welche Bauteile in einem Produkt verbaut sind, muss ein Unternehmen wissen, welche Software-Komponenten in seinen Anwendungen stecken — insbesondere um bei bekanntgewordenen Schwachstellen schnell reagieren zu können.

NTIA-Mindestanforderungen

Die US-amerikanische National Telecommunications and Information Administration (NTIA) hat sieben Mindestfelder für eine SBOM definiert, die sich international als Referenz etabliert haben: Name des Lieferanten, Komponentenname, Versionsnummer, eindeutiger Bezeichner, Abhängigkeitsbeziehungen zwischen Komponenten, Autor der SBOM und Zeitstempel der Erstellung. Diese Mindestanforderungen stellen sicher, dass eine SBOM nicht nur existiert, sondern auch maschinell auswertbar und über Organisationsgrenzen hinweg austauschbar ist.

Formate: SPDX und CycloneDX

In der Praxis haben sich zwei Formate durchgesetzt. SPDX (Software Package Data Exchange) ist ein Projekt der Linux Foundation und seit 2021 ein ISO-Standard (ISO/IEC 5962). Es wird häufig in behördlichen Beschaffungsanforderungen referenziert und deckt neben Sicherheitsaspekten auch Lizenzinformationen ab. CycloneDX wurde von der OWASP Foundation entwickelt und legt den Schwerpunkt auf Security und Vulnerability Management. CycloneDX bietet ein streng definiertes Objektmodell, das komplexe Abhängigkeitsbeziehungen effizient abbildet. Beide Formate unterstützen JSON- und XML-Serialisierung und sind in gängige CI/CD-Pipelines integrierbar.

SBOM und Schwachstellenmanagement

Der eigentliche Mehrwert einer SBOM zeigt sich im Ernstfall. Wird eine kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt — wie 2021 bei Log4Shell — stehen Unternehmen ohne SBOM vor der Frage, ob und wo die betroffene Komponente überhaupt eingesetzt wird. Mit einer aktuellen SBOM lässt sich diese Frage in Minuten beantworten statt in Tagen. Die Kombination aus SBOM und CVSS-Bewertung ermöglicht eine präzise Priorisierung: Welche Systeme sind betroffen, wie kritisch ist die Schwachstelle, und wo muss zuerst gepatcht werden?

Tools wie Dependency-Track oder Grype gleichen SBOMs automatisiert gegen Schwachstellendatenbanken ab und erzeugen Alerts, sobald eine bekannte Verwundbarkeit eine eingesetzte Komponente betrifft. Damit wird die SBOM zur Grundlage eines kontinuierlichen Schwachstellenmonitorings.

Erstellung und Pflege

Eine SBOM kann auf verschiedenen Wegen entstehen. Die gängigste Methode ist die automatisierte Generierung im Build-Prozess: Tools wie Syft, Trivy oder cdxgen analysieren Paketmanager-Lockfiles, Container-Images oder Binärdateien und erzeugen eine vollständige Komponentenliste. Entscheidend ist, dass die SBOM nicht als einmalige Momentaufnahme verstanden wird, sondern als lebendiges Dokument, das bei jedem Release aktualisiert wird. In modernen CI/CD-Pipelines lässt sich die SBOM-Generierung als fester Build-Schritt integrieren — vergleichbar mit Linting oder Unit-Tests.

Regulatorischer Kontext

Mehrere regulatorische Rahmenwerke fordern oder empfehlen SBOMs. Die NIS2-Richtlinie verlangt von Unternehmen ein dokumentiertes Risikomanagement in der Lieferkette — eine SBOM ist hier ein zentrales Umsetzungsinstrument. Der EU Cyber Resilience Act (CRA) wird ab 2027 für Produkte mit digitalen Elementen eine SBOM verpflichtend machen. In den USA hatte Executive Order 14028 SBOM-Anforderungen für Bundesbehörden-Zulieferer eingeführt, auch wenn die verpflichtende Attestierung inzwischen gelockert wurde. Unternehmen, die international liefern oder regulierte Branchen bedienen, kommen um das Thema SBOM nicht mehr herum.

Relevanz für KMUs

Für mittelständische Unternehmen ist die SBOM ein pragmatisches Werkzeug zur Reduzierung von Lieferkettenrisiken. Viele KMUs setzen Open-Source-Komponenten ein, ohne einen vollständigen Überblick über deren Abhängigkeiten und transitive Abhängigkeiten zu haben — eine einzelne npm- oder Python-Bibliothek kann dutzende weitere Pakete mitbringen. Eine SBOM schafft genau diese Transparenz und macht sichtbar, was sonst in der Tiefe des Dependency-Trees verborgen bleibt.

Der Einstieg muss nicht komplex sein: Die oben genannten Tools generieren SBOMs automatisiert aus bestehenden Projekten, ohne Änderungen am Quellcode zu erfordern. Wer regelmäßige Schwachstellenprüfungen mit einer aktuellen SBOM kombiniert, kann Sicherheitslücken in Drittkomponenten frühzeitig identifizieren und gezielt beheben — bevor Angreifer sie ausnutzen oder ein Zero-Day-Exploit bekannt wird.