Was ist ein SBOM? Software-Lieferkettensicherheit erklärt

Eine Software-Stückliste (SBOM) ist ein formales, maschinenlesbares Verzeichnis aller Komponenten, Bibliotheken und Abhängigkeiten, aus denen eine Software besteht, sowie der Lieferkettenbeziehungen zwischen ihnen.

Eine Software-Builder-Map (SBOM) listet die Bestandteile einer Software auf: den Quellcode des Anbieters, Drittanbieterbibliotheken, Open-Source-Pakete sowie deren Versionen und Abhängigkeiten. Sicherheitsteams nutzen sie, um bei Bekanntwerden neuer Sicherheitslücken schnell anfällige Komponenten zu finden, Beschaffungs- und regulatorische Anforderungen zu erfüllen und Risiken entlang der gesamten Software-Lieferkette zu managen. Die beiden gängigsten SBOM-Formate sind CycloneDX und SPDX.

Wichtige Erkenntnisse

• Ein SBOM (Supply-Body Object Model) ist ein maschinenlesbares Inventar aller Komponenten einer Software, das dazu dient, Schwachstellen zu finden, Compliance-Anforderungen zu erfüllen und Lieferkettenrisiken zu managen.
• Die beiden gängigsten und weitverbreiteten SBOM-Formate sind CycloneDX (OWASP, standardisiert als ECMA-424) und SPDX (ein ISO/IEC-Standard). Die meisten Tools können beide Formate erzeugen.
• Die US-Bundespolitik bezüglich SBOMs änderte sich 2025 und 2026: Die Executive Order 14306 (Juni 2025) änderte frühere Anordnungen, und die OMB-Richtlinie M-26-05 (Januar 2026) führte einen behördengesteuerten, risikobasierten Ansatz ein. SBOMs sind nicht mehr einheitlich per Bestätigung vorgeschrieben, können aber weiterhin von den Behörden verlangt werden.
• Der seit Dezember 2024 geltende EU-Akt zur Cyberresilienz führt SBOM-bezogene Verpflichtungen für Produkte mit digitalen Elementen ein, wobei die wichtigsten Anwendungsdaten in den Jahren 2026 und 2027 liegen.
• A Stückliste für Kryptographie (CBOM) erweitert die SBOM-Idee auf kryptografische Assets und bildet damit die Brücke zwischen der Sicherheit der Software-Lieferkette und der Bereitschaft für die Zeit nach der Quantencomputertechnologie.

Warum die Sicherheit der Software-Lieferkette wichtig ist

Moderne Software wird zusammengesetzt, nicht von Grund auf neu geschrieben. Eine typische Anwendung bindet Hunderte von Open-Source- und Drittanbieterkomponenten ein, die jeweils eigene Abhängigkeiten mit sich bringen können. Dieser Abhängigkeitsbaum bildet die Lieferkette der Software, und jede Komponente darin stellt ein potenzielles Einfallstor für Angreifer dar.

Zwei Vorfälle machten dies der gesamten Branche deutlich. Der SolarWinds-Angriff von 2020 schleuste Schadcode in ein legitimes, signiertes Software-Update ein, das anschließend an Tausende von Organisationen verteilt wurde. Die Log4Shell-Schwachstelle in der weit verbreiteten Log4j-Logging-Bibliothek im Jahr 2021 legte unzählige Anwendungen offen, und viele Organisationen konnten eine grundlegende Frage nicht schnell beantworten: Nutzen wir Log4j überhaupt, und wenn ja, wo? Ein SBOM (Structured Business Objective) ermöglicht es einer Organisation, diese Frage innerhalb von Minuten statt Wochen zu beantworten.

Was gehört in ein SBOM?

Die US-amerikanische NTIA veröffentlichte 2021 einen Basissatz von Mindestelementen für ein SBOM, auf den sich die meisten Rahmenwerke weiterhin beziehen. Ein SBOM erfasst mindestens Folgendes:

• Bauteilname und Lieferant: Was die einzelnen Komponenten sind und wer sie hergestellt hat.
• Ausführung. Die spezifische Version jeder Komponente, damit bekannte, anfällige Versionen identifiziert werden können.
• Eindeutige Kennungen: Maschinenlesbare Kennungen wie Paket-URL (purl) oder CPE.
• Abhängigkeitsbeziehungen: Wie die Komponenten miteinander in Beziehung stehen, einschließlich transitiver Abhängigkeiten.
• Autor und Zeitstempel: Wer hat das SBOM erstellt und wann?

Im Jahr 2025 veröffentlichte CISA einen Entwurf zur Aktualisierung der Mindestanforderungen, der Felder wie Komponenten-Hash, Lizenz und Generationskontext hinzufügt. Stand Juli 2026 befinden sich die CISA-Mindestanforderungen von 2025 weiterhin in der öffentlichen Kommentierungsphase und begründen keine neuen rechtlichen Anforderungen. Daher bleibt die NTIA-2021-Basislinie die sichere Grundlage für zukünftige Entwicklungen.

SBOM-Formate: CycloneDX und SPDX

Zwei Formate sind weit verbreitet und werden von praktisch allen gängigen Frameworks akzeptiert. Es empfiehlt sich, Tools zu wählen, die beide Formate ausgeben können, da verschiedene Kunden und Regulierungsbehörden unterschiedliche Formate fordern können.

Attribut	CycloneDX	SPDX
Steward	OWASP; standardisiert als Ecma ECMA-424	Linux Foundation; standardisiert als ISO/IEC 5962
Ursprünglicher Fokus	Sicherheit und Risiko	Einhaltung der Open-Source-Lizenzbestimmungen
Stücklistentypen	SBOM, CBOM, HBOM, SaaSBOM, OBOM, AI/ML-BOM	In erster Linie SBOM, mit wachsenden Sicherheitsbereichen
Formate	JSON, XML, Protocol Buffers	JSON, YAML, RDF, Tag-Wert, Tabellenkalkulation
Unterstützung für Kryptographie	Native CBOM (seit Version 1.6)	Schwellenländer

Für einen detaillierteren Vergleich siehe den Artikel von EC über CBOM vs. SBOM sowie die Erklärung zu CycloneDX.

Die regulatorische Landschaft der SBOM im Jahr 2026

Die SBOM-Regulierung ist real, aber im Wandel begriffen, und die US-Bundeslage hat sich in den Jahren 2025 und 2026 deutlich verändert. Es ist sinnvoll, dies klarzustellen, anstatt ältere Behauptungen zu wiederholen, dass eine einzige Exekutivverordnung SBOMs überall vorschreibt.

USA

Mit der Executive Order 14028 (Mai 2021) wurde die Einführung des modernen SBOM (Self-Business Object Model) auf Bundesebene eingeleitet und die NTIA (National Technology Information Administration) angewiesen, Mindestanforderungen zu veröffentlichen. Die Executive Order 14306 (6. Juni 2025) änderte die zwischenzeitlich erlassene Executive Order 14144, indem sie mehrere erweiterte Zertifizierungsauflagen aufhob, während die Sicherheit der Software-Lieferkette, Post-Quanten-Kryptographie und sichere Entwicklung weiterhin Priorität hatten. Das OMB-Memorandum M-26-05 (23. Januar 2026) hob daraufhin die früheren Zertifizierungsmemoranden M-22-18 und M-23-16 auf und führte die Bundesbehörden zu einem behördengesteuerten, risikobasierten Ansatz.

Die praktische Folge: Bundesbehörden sind nicht mehr einheitlich verpflichtet, ein standardisiertes Bestätigungsformular zu erheben, können aber weiterhin vertraglich SBOMs auf Grundlage ihrer eigenen Risikobewertung verlangen. M-26-05 weist ausdrücklich darauf hin, dass Behörden, die von einem Cloud-Service-Anbieter ein SBOM benötigen, dieses auch für die Laufzeit-Produktionsumgebung anfordern sollten. Branchen- und behördenspezifische Vorgaben bleiben weiterhin bestehen, darunter eine Anfang 2025 erlassene Richtlinie der US-Armee und die seit März 2023 geltende SBOM-Pflicht der FDA für Medizinprodukte.

Europäische Union

Der EU-Akt zur Stärkung der Cybersicherheit (Cyber ​​Resilience Act, CRA) trat im Dezember 2024 in Kraft und gilt für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die auf dem EU-Markt vertrieben werden. Er führt Transparenzpflichten im Zusammenhang mit dem Umgang mit Sicherheitslücken und dem SBOM (Self-Business Outsourcing) ein, die stufenweise Anwendung finden. Die Meldepflichten für Sicherheitslücken und Vorfälle gelten ab dem 11. September 2026, die umfassenderen Anforderungen ab dem 11. Dezember 2027. Unternehmen, die digitale Produkte in der EU verkaufen, sollten diese Termine bereits jetzt in ihre Planung einbeziehen.

Die Reiserichtung

Auch dort, wo die Anforderungen an die Zertifizierung gelockert wurden, bleibt die grundlegende Erwartung bestehen: Käufer, Aufsichtsbehörden und große Unternehmen erwarten zunehmend, dass Softwarehersteller auf Anfrage ein maschinenlesbares SBOM erstellen können. Am sichersten ist es, die SBOM-Erstellung als Standardfähigkeit und nicht als einmalige Compliance-Maßnahme zu betrachten.

Wie SBOMs in der Praxis eingesetzt werden

• Reaktion auf Sicherheitslücken: Wenn eine neue CVE-Schwachstelle auftritt, fragen Sie Ihre SBOMs ab, um jedes Produkt zu finden, das die betroffene Komponente und Version enthält.
• Beschaffungs- und Lieferantenrisiko: Fordern Sie vor dem Kauf SBOMs von den Lieferanten an, um zu verstehen, was Sie tatsächlich einsetzen.
• Lizenzkonformität: Um rechtliche Risiken zu vermeiden, sollten Open-Source-Lizenzen innerhalb der Abhängigkeitsstruktur verfolgt werden.
• Reaktion auf Vorfälle: Bei einem Zwischenfall verkürzt ein SBOM die Zeit zur Bestimmung des Explosionsradius.
• Kontinuierliche Überwachung: Generieren Sie bei jedem Build ein SBOM, damit der Bestand bei Codeänderungen stets aktuell bleibt.

Von SBOM zu CBOM: Die Verbindung zur Kryptographie

Ein SBOM (Software Business Object Model) zeigt Ihnen, welche Softwarekomponenten Sie verwenden. Es gibt jedoch keine Auskunft darüber, welche Kryptografie diese Komponenten nutzen. Diese Lücke ist jetzt relevant, da die Migration zu Post-Quanten-Kryptografie (PQC) die genaue Kenntnis der in einer Umgebung verwendeten Algorithmen, Schlüssellängen, Zertifikate und Protokolle voraussetzt.

Eine kryptografische Stückliste (CBOM) erweitert das SBOM-Konzept auf kryptografische Assets. Sie erfasst Algorithmen, Schlüssel, Zertifikate und die zugehörigen Protokolle sowie deren Beziehungen zu Softwarekomponenten. CycloneDX führte in Version 1.6 (April 2024) native CBOM-Unterstützung ein und erweiterte diese in Version 1.7 (Oktober 2025). Da eine CBOM im selben CycloneDX-Dokument wie eine SBOM dargestellt werden kann, bietet sie Organisationen, die bereits SBOMs erstellen, einen einfachen Einstieg in die kryptografische Bestandsaufnahme.

Dies ist die Brücke zwischen der Sicherheit der Software-Lieferkette und der Quantencomputing-Bereitschaft. Das NIST standardisierte seine ersten Post-Quanten-Algorithmen im August 2024 ( ML-KEM als FIPS 203 und ML-DSA als FIPS 204), und eine Migration im Bereich der Kryptografie ist ohne eine Bestandsaufnahme nicht möglich. Das CBOM (Cryptography Base Model) dient dem Aufbau und der Aktualisierung dieser Bestandsaufnahme.

Wie Verschlüsselungsberatung hilft

Der CBOM Secure- Service von Encryption Consulting erweitert die Transparenz Ihrer Software-Lieferkette um Kryptografie. Er scannt Ihre Umgebung nach Algorithmen, Schlüsseln, Zertifikaten und Protokollen und erstellt eine Kryptografie-Stückliste im CycloneDX-Format, die Ihre bestehenden SBOMs ergänzt. So werden kryptografische Risiken genauso transparent wie Komponentenrisiken. Für Ihre entwickelte und ausgelieferte Software schützt CodeSign Secure die Integrität der Lieferkette, indem die Codesignierung hinter einem FIPS 140-2 Level 2 HSM zentralisiert wird. Dadurch sind die in Ihrer SBOM beschriebenen Artefakte nachweislich authentisch und manipulationssicher. Der Service basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Was ist ein SBOM in einfachen Worten?

Eine SBOM (Software Bill of Materials) ist eine Liste aller Bestandteile einer Software: des eigenen Quellcodes sowie aller Drittanbieter- und Open-Source-Komponenten, von denen sie abhängt, inklusive Versionen und Abhängigkeiten. Man kann sie sich wie eine Zutatenliste für Software vorstellen. Wird eine Schwachstelle in einer Komponente entdeckt, ermöglicht die SBOM einem Unternehmen, schnell zu erkennen, welche Produkte diese Komponente enthalten und daher Aufmerksamkeit erfordern.

Worin besteht der Unterschied zwischen einem SBOM und einem CBOM?

Eine Software-Stückliste (SBOM) erfasst Softwarekomponenten: Bibliotheken, Pakete und deren Versionen. Eine Kryptografie-Stückliste (CBOM) erfasst kryptografische Ressourcen: Algorithmen, Schlüssel, Zertifikate und Protokolle. Die CBOM erweitert das Konzept der SBOM, indem sie nicht nur die Frage beantwortet, welche Software ausgeführt wird, sondern auch, welche Kryptografie sie verwendet. CycloneDX kann beides im selben Dokument darstellen, und die CBOM ist ein grundlegender Schritt hin zur Post-Quanten-Kryptografie.

Sind SBOMs rechtlich vorgeschrieben?

Das hängt von der jeweiligen Gerichtsbarkeit und Branche ab. In den USA änderte sich die Bundespolitik bezüglich SBOMs in den Jahren 2025 und 2026: Mit der Executive Order 14306 und dem OMB-Memorandum M-26-05 wurden die Behörden zu einem risikobasierten Ansatz verpflichtet. Daher sind SBOMs nicht mehr einheitlich durch ein standardisiertes Bestätigungsformular vorgeschrieben, können aber weiterhin vertraglich gefordert werden. In der EU führt der Cyber ​​Resilience Act SBOM-bezogene Verpflichtungen für Produkte mit digitalen Elementen ein, die bis 2026 und 2027 schrittweise eingeführt werden. Die FDA verlangt SBOMs für bestimmte Zulassungsanträge für Medizinprodukte.

Was sind die wichtigsten SBOM-Formate?

Die beiden gängigsten Formate sind CycloneDX und SPDX. CycloneDX, ein OWASP-Projekt, standardisiert als ECMA-424, wurde ursprünglich mit Fokus auf Sicherheit entwickelt und unterstützt verschiedene Stücklistentypen, einschließlich Kryptografie (CBOM). SPDX, standardisiert als ISO/IEC 5962, wurde ursprünglich für die Einhaltung von Lizenzbestimmungen entwickelt. Beide Formate sind weit verbreitet, und die meisten SBOM-Tools können beide Formate erzeugen. Die praktische Wahl hängt daher oft von den Anforderungen des jeweiligen Kunden oder der Aufsichtsbehörde ab.

Wie hilft ein SBOM bei Angriffen vom Typ SolarWinds oder Log4Shell?

Sowohl beim SolarWinds-Angriff 2020 als auch bei der Log4Shell-Schwachstelle 2021 bestand die größte Herausforderung für viele Unternehmen zunächst darin, ob und wo sie betroffen waren. Dank der hinterlegten SBOMs (Software Business Object Models) können Unternehmen gezielt nach einer bestimmten Komponente und Version suchen und sofort alle betroffenen Produkte auflisten. Dadurch verkürzt sich eine mehrwöchige Untersuchung erheblich – ein entscheidender Unterschied zwischen begrenzten und weitreichenden Auswirkungen während eines akuten Sicherheitsvorfalls.

Welcher Zusammenhang besteht zwischen SBOMs und Post-Quanten-Kryptographie?

Die Migration nach der Quantencomputer-Änderung erfordert Kenntnisse über die in Ihren Systemen verwendeten kryptografischen Algorithmen und Schlüssellängen. Algorithmen wie RSA und ECDSA müssen durch quantenresistente Standards wie ML-KEM (FIPS 203) und ML-DSA (FIPS 204) ersetzt werden. Eine Kryptografie-Stückliste (CBOM), die das SBOM-Konzept auf kryptografische Assets erweitert, dient der Erstellung dieses Inventars. Organisationen, die bereits SBOMs erstellen, können die CycloneDX-Tools nutzen, um auch eine CBOM zu generieren.

Erweitern Sie die Sicherheit Ihrer Lieferkette auf Ihre Kryptografie

Ein SBOM sichert Ihre Softwarekomponenten. Ein CBOM sichert die darin enthaltene Kryptografie und ist der erste Schritt zur Post-Quanten-Bereitschaft. Erfahren Sie, wie CBOM Secure Ihr kryptografisches Inventar erstellt, oder entdecken Sie CodeSign Secure zum Schutz der Integrität Ihrer ausgelieferten Software.