Thought Leadership
Transparenz in der Software-Lieferkette verankern und Sicherheitslücken präzise identifizieren. Eine Software Bill of Materials ist die Dokumentation für Anwendungsschutz.
Wobei kann SBOM helfen? Die Erstellung und Bereitstellung von Softwareanwendungen in modernen Unternehmen folgt heute selten dem Prinzip der vollständigen Eigenentwicklung. Software-Ingenieure greifen flächendeckend auf bestehende Bausteine zurück, um Entwicklungszyklen zu verkürzen und betriebswirtschaftliche Effizienz zu sichern. Eine typische Enterprise-Anwendung besteht zu einem überwiegenden Anteil aus Open-Source-Bibliotheken, Frameworks von Drittanbietern und cloudnativen Microservices. Diese modulare Bauweise erzeugt jedoch eine weitreichende Intransparenz über die tatsächlich im Code enthaltenen Komponenten.
Wenn eine tief in den Systemstrukturen vergrabene Open-Source-Bibliothek eine kritische Sicherheitslücke aufweist, wissen IT-Sicherheitsverantwortliche oft wochenlang nicht, welche ihrer internen Anwendungen dieses spezifische Modul überhaupt nutzen. Eine Software Bill of Materials, abgekürzt SBOM, löst dieses informationelle Defizit auf. Es handelt sich um eine formale, maschinenlesbare und strukturierte Dokumentation, die alle enthaltenen Komponenten, Bibliotheken, Abhängigkeiten und hierarchischen Beziehungen einer Softwarelösung lückenlos auflistet. Man kann sich eine SBOM wie eine detaillierte Zutatenliste für Lebensmittel oder ein technisches Teilegutachten in der Automobilindustrie vorstellen.
CISA-Mindestanforderungen einer SBOM
Das Konzept der SBOM hat durch die Zunahme von Lieferketten-Angriffen, wie den Vorfällen rund um SolarWinds oder die Sicherheitslücke in Log4j, eine rapide technologische Standardisierung erfahren. Die Definition dessen, was eine rechtskonforme und technisch verwertbare Stückliste ausmacht, wurde maßgeblich durch US-amerikanische Bundesbehörden und europäische Regulierungsgremien geprägt. Die Cybersecurity and Infrastructure Security Agency, kurz CISA, hat die ursprünglichen Anforderungen der National Telecommunications and Information Administration erweitert und aktualisierte Mindestelemente für eine SBOM definiert.
Eine standardisierte SBOM muss bestimmte Datenfelder zwingend enthalten, um eine automatisierte Weiterverarbeitung in Sicherheitswerkzeugen zu erlauben. Zu diesen Pflichtangaben gehören der Name des Software-Produzenten, der exakte Name der Komponente sowie die spezifische Versionsnummer des Moduls. Zudem sind eindeutige Software-Identifikatoren erforderlich. Hierzu zählen das Format der Common Platform Enumeration (CPE) oder sogenannte Package Uniform Resource Locators, kurz PURL.
Diese Identifikatoren dienen als universelle Suchschlüssel, mit denen automatisierte Sicherheitsscanner eine Komponente in globalen Schwachstellen-Datenbanken eindeutig identifizieren können. Darüber hinaus muss die SBOM die exakten hierarchischen Abhängigkeiten abbilden, also dokumentieren, welches Modul als Unterkomponente in eine andere Bibliothek eingebettet ist. Ein präziser Zeitstempel der Erstellung sowie Angaben zum Autor der Metadaten komplettieren den vorgeschriebenen Datensatz.
Die beiden führenden Austauschformate: SPDX und CycloneDX
Damit eine SBOM ihre Schutzwirkung im IT-Betrieb entfalten kann, darf sie nicht als unstrukturierter Text oder als einfache Tabellenkalkulation vorliegen. Die Daten müssen in standardisierten, maschinenlesbaren Formaten codiert sein, die einen plattformübergreifenden Austausch zwischen Softwareherstellern, Einkäufern und IT-Sicherheitssystemen ermöglichen. Auf dem globalen Technologiemarkt haben sich im Wesentlichen zwei Formate durchgesetzt.
Das erste Format ist Software Package Data Exchange, kurz SPDX. Dieses Format wurde von der Linux Foundation entwickelt und ist als internationaler Standard unter ISO/IEC 5962 zertifiziert. SPDX zeichnet sich durch eine sehr hohe Detailtiefe aus und erfasst neben den reinen Softwarekomponenten auch umfassende Lizenzinformationen, Urheberrechte und kryptografische Dateihashes.
Das zweite Format ist CycloneDX, das von der Open Web Application Security Project Allianz gepflegt wird. CycloneDX wurde von Beginn an als leichtgewichtiges Format speziell für Sicherheitsanalysen und den Einsatz in automatisierten DevSecOps-Pipelines konzipiert. Es erlaubt neben der reinen Auflistung von Software-Komponenten auch die Beschreibung von Cloud-Services, APIs, Hardware-Stücklisten und Schwachstellen-Verknüpfungen. Beide Formate unterstützen moderne Datenstrukturen wie JSON, XML oder YAML und lassen sich nahtlos in automatisierte Sicherheitsarchitekturen integrieren.
Ein struktureller Vergleich der Dokumentationsformen
Um die spezifische Funktion einer SBOM innerhalb des IT-Managements abzugrenzen, hilft ein systematischer Vergleich mit anderen etablierten Inventarisierungs- und Analysewerkzeugen.
| Kriterium | Quellcode-Repository (z. B. Git) | Traditionelles IT-Asset-Inventar | Software Bill of Materials (SBOM) |
| Inhaltliche Basis | Roher Programmcode und Entwicklungsverlauf | Physische Server, Laptops und installierte Software-Suiten | Komponenten, Open-Source-Bibliotheken und transitive Abhängigkeiten |
| primärer Einsatzzweck | Softwareentwicklung und Versionskontrolle | Lizenzmanagement, Hardware-Abschreibung und IT-Einkauf | Schwachstellen-Tracking, Compliance-Nachweis und Lieferkettenschutz |
| Maschinenlesbarkeit | Hoch (über Entwicklerwerkzeuge) | Variabel (oft proprietäre Datenbanken) | Standardisiert (zwingend über SPDX oder CycloneDX) |
| Transparenz-Tiefe | Vollständig für Eigenode, blind für kompilierte Drittanbieter-Bibliotheken | Erkennt nur die Hauptanwendung, nicht deren interne Bibliotheken | Schaut tief in die Anwendungsstruktur hinein, inklusive aller Unterkomponenten |
| Zielgruppe | Software-Entwickler und Systemarchitekten | IT-Service-Manager und kaufmännische Leiter | IT-Sicherheitsbeauftragte, Auditoren und Chief Information Security Officers |
Das Zusammenspiel mit VEX zur Reduzierung von Fehlalarmen
Die reine Generierung einer SBOM löst im täglichen Sicherheitsbetrieb zunächst eine logistische Herausforderung aus. Wenn ein Unternehmen für jede genutzte Software eine detaillierte Stückliste mit Tausenden von Unterkomponenten erhält, schlagen automatisierte Schwachstellenscanner kontinuierlich an, sobald in einer dieser Bibliotheken eine Sicherheitslücke gemeldet wird.
In vielen Fällen ist die betroffene Bibliothek innerhalb der Hauptanwendung jedoch so konfiguriert, dass der fehlerhafte Programmcode niemals ausgeführt wird oder durch vorgeschaltete Sicherheitsmechanismen komplett blockiert ist. Die Sicherheitslücke ist in diesem spezifischen Kontext also gar nicht ausnutzbar. Eine reine Verknüpfung der SBOM mit Schwachstellen-Datenbanken erzeugt daher eine immense Welle an Fehlalarmen, die wertvolle Ressourcen im Security Operations Center bindet.
Um diese Ineffizienz zu beheben, wird das Konzept der SBOM zwingend mit dem Vulnerability Exploitability eXchange, kurz VEX, kombiniert. VEX ist ein standardisiertes Berichtsformat, das als komplementärer Datenstrom zur SBOM fungiert. Über ein VEX-Dokument kann der Softwarehersteller seinen Kunden maschinenlesbar mitteilen, wie der Status einer neu entdeckten Schwachstelle in Bezug auf sein Produkt einzustufen ist.
Das Format kennt vier Statusmeldungen: Nicht betroffen, Betroffen, Behoben oder In Untersuchung. Wenn ein Sicherheits-Scanner eine Schwachstelle in einer SBOM-Komponente findet, prüft er parallel das VEX-Dokument des Herstellers. Steht dort, dass das Produkt aufgrund fehlender Code-Ausführung nicht betroffen ist, wird der Alarm automatisch unterdrückt. Dies reduziert den manuellen Prüfaufwand für IT-Sicherheitsteams drastisch und lenkt die Aufmerksamkeit auf die realen Risikofaktoren.
Regulatorische Verpflichtungen unter NIS2 und dem Cyber Resilience Act
Die Erstellung und Weitergabe von Software-Stücklisten hat sich von einer empfohlenen Sicherheitsmaßnahme zu einer harten gesetzlichen Verpflichtung für Unternehmen gewandelt. Die europäische Gesetzgebung treibt die Digitalisierung von Kontrollmechanismen über weitreichende Verordnungen massiv voran. Die europäische NIS2-Richtlinie verpflichtet Organisationen in wichtigen und kritischen Sektoren zu einem umfassenden Risikomanagement, das explizit die Überwachung der Sicherheit in der Lieferkette einfordert.
Noch spezifischer greift der europäische Cyber Resilience Act, dessen regulatorische Anforderungen ab September 2026 verbindlich für alle Produkte mit digitalen Elementen auf dem europäischen Markt gelten. Der Gesetzestext verlangt von Herstellern, dass sie während des gesamten Lebenszyklus eines Produkts alle enthaltenen Schwachstellen und Komponenten lückenlos dokumentieren. Das Ziehen und Vorhalten einer SBOM in einem commonly used und machine-readable Format ist im Anhang I der Verordnung als fundamentale Pflicht verankert.
Das deutsche Bundesamt für Sicherheit in der Informationstechnik überwacht diese Anforderungen im nationalen Rahmen und stellt im IT-Grundschutz-Kompendium detaillierte Umsetzungshinweise bereit, nachzulesen auf dem offiziellen Portal. Hersteller, die keine ordnungsgemäße SBOM vorweisen können oder die Auskunft gegenüber Marktüberwachungsbehörden verweigern, riskieren unter dem CRA empfindliche Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent ihres weltweiten Jahresumsatzes.
Fazit
Eine Software Bill of Materials ist das unumstößliche Fundament für informationelle Souveränität und Transparenz im digitalen Zeitalter. Sie beendet die Zeit der Black-Box-Software und zwingt Produzenten wie Konsumenten zu einer lückenlosen Verantwortung über die genutzten digitalen Bausteine. Für das moderne IT-Management ist die automatisierte Erstellung, Pflege und Analyse von SBOMs innerhalb der DevSecOps-Pipeline eine elementare Pflichtaufgabe zur Aufrechterhaltung der betrieblichen Resilienz und der gesetzlichen Konformität. Wer die Zusammensetzung seiner Software präzise dokumentiert, minimiert die Angriffsfläche bei globalen IT-Sicherheitskrisen und schafft die notwendige Vertrauensbasis für eine sichere und zukunftsfähige digitale Wirtschaft.
