SBOM erklärt: Transparenz für Software-Lieferketten

Software besteht nur noch selten aus vollständig selbst entwickeltem Code. Bibliotheken, Frameworks und externe Komponenten sind heute ein fester Bestandteil nahezu jeder Anwendung. Diese Anwendungen bestehen überwiegend aus Open-Source- oder kommerziellen Drittanbieter-Komponenten.

Viele dieser Komponenten werden automatisch eingebunden, regelmäßig aktualisiert oder indirekt über weitere Abhängigkeiten nachgezogen. Dabei entstehen sogenannte transitive Abhängigkeiten: Komponenten, die nicht direkt eingebunden wurden, sondern als Abhängigkeit einer Abhängigkeit Teil der Software werden. Mit jeder zusätzlichen Abhängigkeit wächst die Komplexität und damit auch die Herausforderung, den Überblick zu behalten.

In der Praxis entsteht dadurch eine Situation, in der Software betrieben wird, ohne dass vollständig nachvollziehbar ist, woraus sie tatsächlich besteht. Komponenten sind vorhanden, ihre Herkunft ist oft bekannt, ihr konkreter Einsatz jedoch nicht immer transparent. In manchen Fällen sind Abhängigkeiten veraltet, nicht mehr gepflegt oder enthalten bekannte Sicherheitslücken.

Spätestens bei neu veröffentlichten Schwachstellen zeigt sich diese fehlende Transparenz: Ist unsere Software betroffen und wenn ja, welche Komponente davon? Ein prominentes Beispiel dafür war die Log4Shell-Schwachstelle (CVE-2021-44228) Ende 2021. In manchen Organisationen dauerte es lange, bis überhaupt klar war, welche Systeme die betroffene Bibliothek enthielten.

Eine Software Bill of Materials (SBOM) setzt genau an diesem Punkt an. Sie schafft eine strukturierte Übersicht über die eingesetzten Komponenten und bildet damit die Grundlage für mehr Transparenz und bessere Entscheidungen im Umgang mit Software-Risiken.

Was ist eine SBOM?

Eine SBOM ist eine strukturierte, maschinenlesbare Liste aller Komponenten, aus denen sich eine Software zusammensetzt. Das Konzept ist vergleichbar mit einer Zutatenliste bei Lebensmitteln. Sie macht sichtbar, was enthalten ist, auch dann, wenn es von außen nicht erkennbar wäre.

Der Begriff SBOM leitet sich von dem allgemeineren Begriff Bill of Materials (BOM) ab. Dieses Konzept stammt ursprünglich aus der Fertigung und beschreibt sämtliche Bauteile und Materialien, die in ein Produkt einfließen. Übertragen auf die Softwarewelt existieren verschiedene Ausprägungen dieses Konzepts:

Die SBOM ist aktuell die Variante, die zunehmend an Relevanz und Aufmerksamkeit gewinnt. Sie bildet in der Regel den Ausgangspunkt, wenn von Transparenz in Software-Lieferketten die Rede ist. Die erhöhte Relevanz ergibt sich neben Security-Anforderungen auch aus regulatorischen Entwicklungen wie dem Cyber Resilience Act (Verordnung (EU) 2024/2847).

Typischerweise enthält eine SBOM Informationen wie:

• verwendete Bibliotheken und Abhängigkeiten (direkte und transitive)
• Versionen der Komponenten
• Hersteller oder Maintainer
• Lizenzinformationen
• eindeutige Identifikatoren (z. B. Package URL / purl oder CPE)
• Beziehungen zwischen Komponenten (Abhängigkeitsbaum)

Ziel ist es, nachvollziehbar zu machen, welche Bausteine in einer Anwendung enthalten sind – und zwar nicht nur für Entwickler, sondern auch für Betrieb, Security-Teams und im Idealfall auch für Kunden und Partner.

Welche Probleme löst eine SBOM?

Ohne SBOM entsteht in vielen Organisationen eine typische Situation: Software wird betrieben, aber niemand kann genau sagen, welche Komponenten darin enthalten sind.

Das führt zu mehreren Herausforderungen:

1. Fehlende Transparenz bei Schwachstellen
   Wird eine neue Schwachstelle veröffentlicht, bleibt oft unklar, ob eigene Systeme betroffen sind. Sicherheitsteams müssen im schlimmsten Fall jedes Projekt einzeln untersuchen. Ein solches Vorgehen führt dazu, dass insbesondere bei größeren Systemlandschaften übermäßig viel Ressourcen eingesetzt werden.

2. Aufwendige Analyse im Incident-Fall
   Im Ernstfall beginnt die Suche nach betroffenen Komponenten erst dann, wenn Zeit kritisch ist. Statt auf vorhandene Daten zurückzugreifen, müssen Informationen manuell zusammengetragen werden. Das kostet Zeit und erhöht das Risiko, betroffene Systeme zu übersehen.

3. Abhängigkeit von Herstellern
   Ohne eigene Übersicht muss man darauf warten, dass Hersteller Informationen zu verwundbaren Softwareversionen liefern. Eine mitgelieferte oder selbst erstellte SBOM für die eingesetzte Software reduziert diese Abhängigkeit erheblich. Dadurch können Abhängigkeiten selbstständig auf neue Schwachstellen geprüft werden.

4. Fehlende Lizenzübersicht
   Ohne systematische Erfassung ist oft nicht nachvollziehbar, unter welchen Lizenzen die eingesetzten Komponenten stehen. Das kann zu unbeabsichtigten Lizenzverstößen führen, etwa wenn eine Bibliothek mit einer Copyleft-Lizenz in ein kommerzielles Produkt einfließt, ohne dass die Lizenzbedingungen eingehalten werden.

5. Mangelnde Nachvollziehbarkeit gegenüber Dritten
   Kunden, Partner oder Gesetzgeber erwarten zunehmend Aussagen darüber, welche Komponenten in einer Software enthalten sind. Ohne SBOM lassen sich solche Fragen nur schwer oder gar nicht beantworten. Das erschwert nicht nur Audits und Nachweise, sondern kann auch dazu führen, dass Anforderungen nicht erfüllt oder Verträge nicht eingehalten werden.

Eine SBOM unterstützt die Adressierung dieser Herausforderungen erheblich. Betroffene Systeme können schneller identifiziert und priorisiert werden. Gleichzeitig schafft sie eine gemeinsame Datenbasis, auf der Security-, Compliance- und Entwicklungsteams aufsetzen können.

Welche SBOM-Formate gibt es?

SBOM ist kein einzelnes Format, sondern ein Konzept mit mehreren etablierten Standards. Die Wahl des Formats ist keine Entweder-Oder-Entscheidung. In der Praxis ist es durchaus üblich, mehrere Formate parallel zu nutzen – etwa CycloneDX für Security-Prozesse und SPDX für Lizenz-Compliance.

Die Wahl des Formats hängt stark vom Anwendungsfall ab. Für Security-Zwecke wird heute häufig CycloneDX eingesetzt. Für regulatorische und lizenzrechtliche Anforderungen ist SPDX eine verbreitete Wahl.

CycloneDX

CycloneDX wurde von Anfang an mit Blick auf Security entwickelt und wird als OWASP-Projekt aktiv gepflegt. Der Standard entstand aus der Notwendigkeit, Softwarezusammensetzungen in dynamischen Entwicklungspipelines transparent und maschinenlesbar zu machen. Er eignet sich hervorragend für die Integration in CI/CD-Prozesse und unterstützt Organisationen bei der kontinuierlichen Überwachung von Abhängigkeiten.

Der Fokus liegt auf:

• Abhängigkeiten und deren Beziehungen (vollständiger Dependency-Graph)
• eindeutiger Identifikation von Komponenten (z. B. über purl)
• Integration in automatisierte Prozesse
• Erweiterbarkeit, z. B. für VEX (Vulnerability Exploitability eXchange), um Aussagen zur tatsächlichen Betroffenheit einer Schwachstelle maschinenlesbar abzubilden

CycloneDX unterstützt sowohl JSON als auch XML als Ausgabeformat und wird von einer breiten Palette an Tools unterstützt. Dadurch eignet sich CycloneDX besonders für DevSecOps-Umgebungen und für die Verknüpfung mit Schwachstelleninformationen.

SPDX

SPDX stammt aus dem Bereich Open-Source-Compliance und wird von der Linux Foundation gepflegt (weitere Informationen). Der Standard ermöglicht eine präzise Dokumentation von Lizenzbedingungen und Komponentenherkunft.

Im Mittelpunkt stehen:

• Lizenzinformationen und deren maschinenlesbare Darstellung
• rechtliche Einordnung von Softwarekomponenten
• Nachvollziehbarkeit der Nutzung von Open Source
• standardisierte Lizenz-Identifikatoren (SPDX License List)

SPDX ist in vielen regulatorischen und rechtlichen Kontexten etabliert, wird aber zunehmend auch für Security-Anwendungsfälle genutzt. Mit der Weiterentwicklung in SPDX 3.0 erweitert sich der Scope deutlich über Lizenzinformationen hinaus: Der Standard soll unter anderem auch Schwachstellen, Build-Informationen, KI-Modelle und Datensätze, Herkunfts- und Integritätsinformationen sowie Beziehungen zwischen Systemelementen abdecken. SPDX 3.0 ist aktuell als ISO/IEC DIS 5962 in Entwicklung.

SWID

SWID-Tags haben ihren Ursprung im Asset- und Lizenzmanagement und sind als ISO-Standard ISO/IEC 19770-2:2015 definiert. Sie bieten eine standardisierte Methode zur Inventarisierung installierter Software in IT-Umgebungen und erleichtern die Verwaltung großer Asset-Bestände.

Eine SWID-Datei beschreibt

• welche Software installiert ist
• von welchem Hersteller sie stammt
• in welcher Version sie vorliegt
• Patch-Stände und Installationsmerkmale

SWID wird häufig in Enterprise-Umgebungen eingesetzt, insbesondere in Verbindung mit bestehenden IT-Management-Systemen. Im Vergleich zu CycloneDX und SPDX liegt der Schwerpunkt weniger auf der Abbildung von Abhängigkeitsbäumen als auf der Identifikation installierter Softwareprodukte.

Wie werden SBOM-Dateien erstellt?

SBOM-Dateien werden meist automatisiert erstellt, entweder direkt im Build-Prozess (z.B. über CI/CD-Pipelines) oder durch die Analyse bestehender Dependency-Dateien wie package-lock.json, composer.lock oder pom.xml. Dabei werden enthaltene Komponenten, Versionen und Abhängigkeiten erfasst und in ein standardisiertes Format wie CycloneDX oder SPDX überführt.

Zusätzlich können laufende Systeme, Container oder bestehende Installationen analysiert werden, um tatsächlich vorhandene Komponenten zu erfassen. In der Praxis entsteht der größte Mehrwert durch die Kombination dieser Ansätze, da so sowohl deklarierte als auch reale Abhängigkeiten sichtbar werden.

Dabei lassen sich zwei grundsätzliche Ansätze unterscheiden:

• Source-/Build-basierte Analyse
  Die SBOM wird aus Quellcode und Build-Artefakten erzeugt. Dieser Ansatz liefert eine genaue Abbildung der deklarierten Abhängigkeiten.
• Runtime-/Image-basierte Analyse
  Die SBOM wird durch die Untersuchung einer laufenden Umgebung oder eines Container-Images erstellt. So werden auch Komponenten erfasst, die nicht über den Paketmanager deklariert sind.

Eine SBOM bleibt dabei immer eine Momentaufnahme. Der bestmögliche Nutzen zur Ermittlung von Schwachstellen entfaltet sich erst durch kontinuierliche Auswertung und Prüfung auf neue Schwachstellen.

Fortlaufende Analyse von SBOM-Dateien

Eine einmal erstellte SBOM kann schnell ein trügerisches Gefühl von Sicherheit vermitteln. Oftmals wird direkt mit der Erstellung einer SBOM-Datei die Abhängigkeiten auch auf bekannte Schwachstellen analysiert. Dies ist vorteilhaft für eine Übersicht, dass keine bekannten Schwachstellen zum Prüfzeitpunkt vorhanden sind.

In einer bereitgestellten Version einer Software bleiben die enthaltenen Komponenten oft gleich. Neue Schwachstellen werden jedoch täglich veröffentlicht und betreffen häufig bereits eingesetzte Software und die darauf abhängigen Komponenten. Nur durch einen kontinuierlichen Abgleich der SBOM gegen aktuelle Schwachstellendaten können betroffene Komponenten frühzeitig erkannt werden.

Erst durch die regelmäßige Analyse gegen aktuelle Schwachstelleninformationen entsteht ein echter Mehrwert:

• verwundbare Komponenten können frühzeitig erkannt werden
• Priorisierung wird fundierter, z.B. in Kombination mit CVSS-Scores (Was ist CVSS?) oder EPSS-Wahrscheinlichkeiten
• Reaktionszeiten verkürzen sich deutlich
• der Sicherheitsstatus einer Anwendung wird über ihren gesamten Lebenszyklus hinweg nachvollziehbar

Eine SBOM ist daher eine funktionierende Grundlage für fortlaufende Erkennung verwundbarer Komponenten in einer Software. Diese Informationen dienen als Ausgangspunkt für eine weitere Beurteilung der Schwere und Auswirkung einer Schwachstelle.

Übersicht von Lizenzen der Komponenten

Neben der Sicherheitsperspektive kann eine SBOM auch eine wertvolle Grundlage für die Lizenz-Compliance liefern. Jede Bibliothek und Komponente bringt eine eigene Lizenz mit.

In der Praxis begegnen einem dabei verschiedene Lizenzmodelle:

• Freizügige Lizenzen
  (z.B. MIT, BSD, Apache 2.0): Erlauben eine weitgehend freie Nutzung, auch in kommerzieller Software. Typischerweise verlangen sie lediglich die Beibehaltung des Lizenz- und Copyright-Hinweises.

• Copyleft-Lizenzen
  (z.B. GPL, AGPL, EUPL): Verlangen, dass abgeleitete Werke unter derselben Lizenz veröffentlicht werden. Je nach Lizenz und Art der Einbindung kann dies erhebliche Auswirkungen auf die eigene Lizenzierung haben.

• Proprietäre oder eingeschränkte Lizenzen
  Kommerzielle Komponenten mit eigenen Nutzungsbedingungen, die individuell geprüft werden müssen.

Ohne systematische Erfassung und Dokumentation entsteht ein unklares Bild über verwendete Lizenzen. In einem Projekt mit mehreren hundert Abhängigkeiten lässt sich kaum manuell nachvollziehen, welche Lizenzbedingungen letztlich gelten. Eine SBOM schafft hier die nötige Grundlage, um Lizenzinformationen maschinenlesbar zu erfassen und auszuwerten.

In Kombination mit spezialisierten Tools lässt sich so ein Überblick schaffen, der zeigt:

• welche Lizenzen im Projekt verwendet werden
• ob Lizenzkonflikte bestehen
• welche Komponenten einer genaueren lizenzrechtlichen Prüfung bedürfen

Gerade bei Produkten, die ausgeliefert oder als Service betrieben werden, ist dieser Überblick essenziell, um Lizenzrisiken frühzeitig zu erkennen.

SBOM im Kontext des Cyber Resilience Act (CRA)

Mit der Verordnung (EU) 2024/2847 (EUR-Lex-Link) rückt die Transparenz in Software-Lieferketten stärker in den Fokus. Der CRA richtet sich grundsätzlich an Hersteller von Produkten mit digitalen Elementen (Hardware/Software, die in der EU vermarktet werden), die Cybersicherheit über den gesamten Lebenszyklus sicherstellen müssen.

Durch den CRA werden Hersteller verpflichtet unterschiedliche Maßnahmen zu ergreifen. Zu diesen zählen beispielsweise:

• Sicherheitsaspekte über den gesamten Lebenszyklus berücksichtigen und gewährleisten.
• Bereitstellung ohne bekannte ausnutzbare Schwachstellen sowie Bereitstellung von Sicherheitsaktualisierungen.
• Dokumentation von verwendeten Komponenten, u.a. durch Erstellung einer Software-Stückliste.
• Eine Schwachstellen-Behandlung (Vulnerability Handling) nachweisbar zu etablieren.

Darüber hinaus fordert der CRA eine koordinierte Schwachstellen-Offenlegung und die Meldung aktiv ausgenutzter Schwachstellen an die ENISA. Eine solche Meldung soll über eine durch die ENISA betriebene Single Reporting Platform (SRP) erfolgen. Diese Plattform wird ab dem 11. September 2026 operativ in Betrieb gehen (weitere Informationen).

Mit dem CRA verschiebt sich der Fokus von freiwilliger Transparenz hin zu nachvollziehbarer Verpflichtung. Organisationen, die bereits heute SBOMs erstellen und aktiv nutzen, schaffen damit nicht nur bessere Sicherheitsprozesse, sondern auch eine Grundlage, um regulatorische Anforderungen frühzeitig zu erfüllen.

Fazit

Eine SBOM schafft Transparenz über die tatsächliche Zusammensetzung von Software. Sie liefert damit eine belastbare Grundlage, um Abhängigkeiten zu verstehen, Risiken zu erkennen und fundierte Entscheidungen zu treffen.

Ihr voller Nutzen entfaltet sich jedoch erst durch die kontinuierliche Auswertung im Kontext aktueller Schwachstelleninformationen. Erst dadurch wird sichtbar, welche Komponenten tatsächlich betroffen sind und wo Handlungsbedarf entsteht.

Gerade im Hinblick auf regulatorische Anforderungen wie den Cyber Resilience Act wird deutlich: Transparenz allein reicht nicht aus. Entscheidend ist die Fähigkeit, diese Informationen strukturiert auszuwerten, zu priorisieren und in konkrete Maßnahmen zu überführen.

Ansätze, die SBOM-Daten mit aktuellen Schwachstelleninformationen verknüpfen und kontinuierlich bewerten, unterstützen Organisationen dabei, genau diesen Schritt zu gehen.