Wie sich CBOM von SBOM unterscheidet und warum es für die Industrie entscheidend ist

Eine kryptografische Stückliste (CBOM) erfasst die kryptografischen Assets, Algorithmen, Schlüssel, Zertifikate und Bibliotheken einer Organisation, während eine Software-Stückliste (SBOM) Softwarekomponenten und Abhängigkeiten katalogisiert. Dies ist relevant, da SBOM-Tools selten die Sicherheitsmaßnahmen von Software erfassen, sondern nur deren Bestandteile. Dadurch entsteht eine Lücke in Bezug auf Compliance und Migration nach der Quantenmigration. Empfohlene Vorgehensweise: Erweitern Sie Ihre bestehende SBOM-Pipeline um CBOM-Daten mithilfe der nativen Krypto-Asset-Unterstützung von CycloneDX 1.6, anstatt ein separates, unabhängiges Inventar zu erstellen.

Wichtige Erkenntnisse

SBOM katalogisiert Softwarekomponenten, Versionen, Lizenzen und CVEs; CBOM katalogisiert kryptografische Algorithmen, Schlüssel, Zertifikate, Protokolle und Bibliotheken – eine völlig andere Ebene der Transparenz.
Mit CycloneDX 1.6 wurde ein nativer Komponententyp „Krypto-Asset“ eingeführt, der CBOM ein standardisiertes, maschinenlesbares Schema verleiht, das durch ECMA-424 und das öffentliche Kryptographie-Register von CycloneDX weiter formalisiert wurde.
CBOM ist das notwendige Inventar für die Migration zur Post-Quanten-Kryptographie: Man kann RSA- oder ECC-Anwendungen nicht ersetzen, die man nicht zuvor lokalisiert und katalogisiert hat.
PCI DSS 4.0, NIST SP 800-57/175B und die CNSA Suite der NSA beziehen sich allesamt auf Anforderungen an das kryptografische Inventar, die ein CBOM direkt erfüllt.
Der schnellste Weg zu einem funktionierenden CBOM besteht darin, eine bestehende SBOM-Pipeline (Syft, OWASP Dependency-Track, CycloneDX-basierte Tools) zu erweitern, anstatt einen separaten Erkennungsprozess von Grund auf neu zu entwickeln.

Veröffentlicht: August 2025. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Wie die NIST-Leitlinien zur Krypto-Agilität direkt mit CBOM als Voraussetzung verknüpft sind, erfahren Sie in „ Wichtige Erkenntnisse aus dem neuesten NIST-Bericht zur Krypto-Agilität“ . Wie ein kryptografisches Inventar im CBOM-Stil einem Bundeskontrollkatalog zugeordnet wird, erfahren Sie in „Erhöhen Sie Ihre Sicherheit mit NIST 800-53“ . Informationen zu den Kryptografie-Richtlinienanforderungen von NIS2, die mithilfe von CBOM erfüllt werden können, finden Sie in „ Alles, was Sie über NIS2-Konformität wissen müssen“.

Was ist ein SBOM?

Eine Software-Stückliste (SBOM) ist eine detaillierte Aufzeichnung aller Softwarepakete, Bibliotheken, Module und Abhängigkeiten einer Anwendung, einschließlich Versionsnummern, Lizenzdetails, Quellcode-Repositorys, Abhängigkeiten und bekannter Sicherheitslücken (CVEs). Die US-amerikanische Exekutivverordnung zur Cybersicherheit von 2021 verpflichtete Softwareanbieter der Bundesregierung zur Erstellung von SBOMs, nachdem eine Welle von Angriffen auf die Software-Lieferkette Tausende von Systemen durch bösartige oder anfällige Komponenten kompromittiert hatte. Die Werkzeuge für die Erstellung von SBOMs sind ausgereift: SPDX und CycloneDX sind etablierte und weit verbreitete Formate.

Was ist ein CBOM?

Eine kryptografische Stückliste (CBOM) ist ein strukturiertes Verzeichnis aller kryptografischen Komponenten in der Software und den Systemen einer Organisation: Verschlüsselungsalgorithmen, digitale Schlüssel, Zertifikate, Kryptoprotokolle und die zugehörigen Bibliotheken. Während die Software-basierte Stückliste (SBOM) die Frage „Welche Software verwende ich?“ beantwortet, beantwortet die CBOM die Frage „Wie ist diese Software tatsächlich geschützt?“, eine Frage, die SBOM-Tools standardmäßig nicht berücksichtigen.

Worin unterscheidet sich CBOM von SBOM?

Funktion	SBOM	CBOM
Fokusbereich	Softwaremodule und Abhängigkeiten	Kryptografische Algorithmen, Schlüssel, Zertifikate und Protokolle
Zweck	Verfolgen Sie Schwachstellen, Lizenzen und Updates	Sichere Verschlüsselungsnutzung und Einhaltung kryptografischer Hygiene
Primäre Benutzer	Entwickler-, DevOps- und AppSec-Teams	Sicherheitsarchitekten, Kryptobesitzer, Compliance-Leiter
Beispielhafte Einträge	Apache Struts, Log4j, React	RSA-2048, TLS 1.2, ein abgelaufenes X.509-Zertifikat, ein SHA-1-Hash
Regulatorische Relevanz	Executive Order 14028, NTIA SBOM-Spezifikationen	PCI DSS 4.0, NIST SP 800-57/175B, CNSA Suite
Reifegrad der Werkzeuge	Ausgereift: SPDX, CycloneDX	Standardisierung: CycloneDX 1.6 Krypto-Asset-Typ, ECMA-424, IBM CBOM-Tools

Wie lassen sich CBOM-Anforderungen Kontrollen, Verantwortlichen und Nachweisen zuordnen?

Anforderung	Angetrieben durch	Kontrolle	Eigentümer	Beweisstück
Inventar der verwendeten kryptografischen Algorithmen	PCI DSS 4.0 Anforderung 12.3.3; NIST SP 800-175B	Automatisierte kryptografische Erkennung durchsucht Binärdateien, TLS-Konfigurationen und Schlüsselspeicher.	Kryptographie-/Sicherheitsarchitekturteam	Aktueller CBOM-Export (CycloneDX-Krypto-Asset-Format)
Lebenszyklus von Zertifikaten verfolgen	Interne Revision; Ausfälle im Zusammenhang mit Zertifikaten	Zentralisiertes Zertifikatsinventar mit Ablaufüberwachung	PKI-/Zertifikatsverwaltungsteam	Bericht über die Plattform zur Verwaltung des Zertifikatslebenszyklus
Quantenanfällige Algorithmen identifizieren	PQC-Migrationsplanung; NIST-Leitfaden für die Zeit nach der Quantenbeschleunigung	CBOM-Kennzeichnung von RSA, ECC und anderen klassischen, anfälligen Algorithmen	PQC-Beratungsteam / Kryptografieteam	PQC-Bereitschaftsbewertung unter Bezugnahme auf das CBOM
Kryptografische Besitzrechte zuweisen	Interne Governance	Ein benannter Krypto-Steward oder eine Kryptographie-Arbeitsgruppe	CISO / Sicherheitsgovernance	Governance-Charta zur Benennung der Rolle und ihrer Verantwortlichkeiten

Welche Implementierungsschritte sind für den Aufbau eines CBOM erforderlich?

Beginnen Sie mit Systemen mit hohem Risiko und hohem Wert: solchen, die regulierte Daten verarbeiten, internetbasiert sind oder bereits einer Compliance-Vorgabe wie PCI DSS oder FedRAMP unterliegen.
Erweitern Sie Ihre bestehende SBOM-Pipeline (Syft, OWASP Dependency-Track oder ein anderes CycloneDX-basiertes Tool) so, dass sie auch den nativen Krypto-Asset-Komponententyp von CycloneDX 1.6 ausgibt, anstatt einen parallelen Prozess zu erstellen.
Ergänzend dazu bietet die SBOM-Erweiterung spezialisierte kryptografische Erkennungsfunktionen, die die Lücken der SBOM-Erweiterung schließen: Scans der TLS-Konfiguration, Inventarisierung von Zertifikaten und Schlüsselspeichern sowie die Erkennung veralteter Algorithmen wie SHA-1 oder RSA-1024.
Weisen Sie einen Krypto-Steward zu oder gründen Sie eine Arbeitsgruppe für Kryptographie, die für das Inventar verantwortlich ist, Richtlinien für den Schlüssellebenszyklus definiert und auf kryptografische Sicherheitslücken reagiert.
Ordnen Sie das resultierende CBOM Ihren tatsächlichen Compliance-Anforderungen zu: PCI DSS 4.0 Anforderung 12.3.3, NIST SP 800-53 Supply Chain Risk Management Familie oder dem PQC-Migrationsplan Ihrer Organisation.
Automatisieren Sie die CBOM-Generierung innerhalb von CI/CD, damit das Inventar den aktuellen Build widerspiegelt und nicht eine Momentaufnahme aus der letzten manuellen Prüfung.

Wie ist der aktuelle Stand der CBOM-Standardisierung?

Die CBOM-Standardisierung hat das Stadium des fehlenden universellen Formats hinter sich gelassen. CycloneDX 1.6 führte einen nativen Krypto-Asset-Komponententyp ein und verlieh CBOM damit ein standardisiertes, maschinenlesbares Schema innerhalb derselben Spezifikation, die die meisten SBOM-Tools bereits verwenden. Diese Arbeit wurde durch ECMA-424 und das öffentliche Kryptografie-Register von CycloneDX weiter formalisiert. Auch die CBOM-Tools und -Forschung von IBM (einschließlich eines auf der Eurocrypt 2026 vorgestellten Papers) spiegeln diese Konvergenz hin zu einem gemeinsamen Schema wider. Die Reife der Tools hinkt zwar noch hinter der von SBOM her, aber die Aussage „Es existiert kein Standard“ ist kein stichhaltiges Argument mehr für den Beginn der Entwicklung.

Welche Einschränkungen gibt es bei der Einführung von CBOM?

Die Identifizierung kryptografischer Elemente ist schwieriger als die Identifizierung von Softwarekomponenten; dazu ist das Parsen von Binärdateien und das Scannen der laufenden Infrastruktur erforderlich, nicht nur das Lesen eines Paketmanifests.
Die Zuständigkeiten sind oft unklar. Sicherheit, DevOps, Entwicklung und Recht können jeweils plausiblerweise ein Interesse an der Kryptographie beanspruchen, und ohne eine explizite Rolle des Krypto-Stewards stocken die CBOM-Bemühungen eher bei der Governance als bei der Entwicklung von Werkzeugen.
Ein CBOM allein behebt noch nichts; er deckt zwar den veralteten Algorithmus oder das abgelaufene Zertifikat auf, aber ein separater Behebungsprozess muss auf diesen Befund reagieren.
Selbst mit dem Schema von CycloneDX 1.6 ist die Entwicklung von Werkzeugen, die automatisch jede kryptografische Implementierung in älteren Binärdateien, eingebetteten Systemen und Hardwaremodulen erkennen, noch nicht abgeschlossen.

Checkliste zur Auditvorbereitung für die Einführung von CBOM

Ein aktueller CBOM-Export im CycloneDX 1.6 Krypto-Asset-Format, der Ihre Systeme mit dem höchsten Risiko abdeckt.
Ein benannter Krypto-Steward oder eine Arbeitsgruppe für Kryptographie mit einer dokumentierten Governance-Charta.
Die Nachverfolgung des Zertifikatslebenszyklus ist in das gesamte kryptografische Inventar integriert und wird nicht separat verwaltet.
Die Ergebnisse der Ermittlung veralteter Algorithmen (SHA-1, RSA-1024 und ähnliche) wurden einem Verantwortlichen für die Behebung und einem Zeitplan zugeordnet.
Die CBOM-Generierung wird innerhalb von CI/CD automatisiert und nicht mehr für jeden Auditzyklus manuell durchgeführt.

Was würde Encryption Consulting empfehlen?

Die meisten Organisationen, mit denen wir sprechen, verfügen zwar über ein ausgereiftes SBOM-Programm, aber kein kryptografisches Äquivalent. Das bedeutet, dass ihrem PQC-Migrationsplan kein tatsächliches Inventar zugrunde liegt. Unsere CBOM Secure- Plattform erstellt und automatisiert dieses kryptografische Inventar direkt. Unsere PQC-Beratungsdienste nutzen es, um einen realistischen Migrationsplan zu entwickeln, und unser CertSecure Manager vervollständigt die Zertifikatslebenszyklus-Hälfte des Inventars, die von herkömmlichen Erkennungstools oft übersehen wird.

Häufig gestellte Fragen

Ist CBOM einfach nur SBOM mit mehr Feldern?

Nein. SBOM katalogisiert Softwarekomponenten; CBOM katalogisiert eine völlig andere Ebene, nämlich kryptografische Algorithmen, Schlüssel, Zertifikate und Protokolle, die die meisten SBOM-Tools ohne gezielte Erweiterung nicht erfassen.

Gibt es mittlerweile ein Standardschema für CBOM?

Ja. CycloneDX 1.6 hat einen nativen Krypto-Asset-Komponententyp hinzugefügt, der durch ECMA-424 und das öffentliche Kryptographie-Register von CycloneDX weiter formalisiert wurde.

Warum ist CBOM für die Migration nach der Quantenkryptographie relevant?

RSA, ECC oder andere klassischerweise als anfällig geltende Algorithmen lassen sich nicht ersetzen, solange sie nicht zuvor lokalisiert wurden. CBOM liefert das grundlegende Inventar, auf dem jeder PQC-Migrationsplan aufbaut.

Welche Compliance-Rahmenwerke beziehen sich auf kryptografische Inventare?

PCI DSS 4.0 Anforderung 12.3.3, NIST SP 800-57 und 800-175B sowie die CNSA Suite der NSA beziehen sich allesamt auf kryptografische Inventar- oder Algorithmeneignungsanforderungen, die ein CBOM direkt erfüllt.

Wer sollte innerhalb einer Organisation für ein CBOM verantwortlich sein?

Ein designierter Crypto Steward oder eine Arbeitsgruppe für Kryptographie, da die Zuständigkeit für Kryptographie ohne eine explizit benannte Rolle tendenziell zwischen Sicherheit, DevOps und Entwicklung liegt, ohne dass jemand dafür verantwortlich ist.

Benötigen Sie Unterstützung bei der Erweiterung Ihrer SBOM-Pipeline zu einem funktionsfähigen CBOM im Vorfeld Ihres nächsten PQC-Migrationsmeilensteins? Sprechen Sie mit dem Compliance Advisory Team von Encryption Consulting.