Kryptografische Stückliste (CBOM): Der Schlüssel zur Sicherung Ihrer Software-Lieferkette

Kurz gesagt: Eine kryptografische Stückliste (CBOM) ist ein strukturiertes Verzeichnis aller Algorithmen, Schlüssel, Zertifikate, Protokolle und kryptografischen Bibliotheken, die Ihre Software und Infrastruktur verwenden. Sie basiert auf dem OWASP CycloneDX-Standard. Sie ist wichtig, da Sie ohne Kenntnis ihrer Speicherorte weder von quantenanfälliger Kryptografie migrieren noch die Konformität nachweisen können. Beginnen Sie mit dem Scannen Ihres Codes, Ihrer Zertifikate und Ihrer Laufzeitumgebungen, um eine Basislinie zu erstellen.

Lieferkettenangriffe sind vielfältig und treffen Unternehmen wie auch Regierungsbehörden. Kommerzielle Software und Open-Source-Pakete sind gleichermaßen Ziele. Daher ist vollständige Transparenz über alle Software- und kryptografischen Assets entlang Ihrer Entwicklungs- und Bereitstellungspipeline eine Grundvoraussetzung und kein bloßes Extra. 

Im Jahr 2020 wurden durch den Lieferkettenangriff auf SolarWinds Tausende von Organisationen und mehrere US-Regierungsbehörden kompromittiert, nachdem Angreifer eine Hintertür namens SUNBURST in das IT-Update-Tool Orion eingeschleust hatten. Im Februar 2021 gelang es dem Sicherheitsforscher Alex Birsan, mithilfe einer Technik namens „Dependency Confusion“ in Systeme von Microsoft, Tesla, Uber und Apple einzudringen. Dabei wurden interne Build-Systeme dazu gebracht, schädliche öffentliche Pakete anstelle der vertrauenswürdigen internen Pakete zu verwenden.

Als Reaktion darauf erließ die US-Regierung im Mai 2021 die Executive Order 14028 mit dem Titel „Verbesserung der nationalen Cybersicherheit“. Diese verpflichtet Softwareanbieter, die an Bundesbehörden verkaufen, eine Software-Stückliste (Software Bill of Materials, SBOM) bereitzustellen. Eine SBOM ist eine maschinenlesbare Liste aller Module, Bibliotheken und Drittanbieterabhängigkeiten einer Software, einschließlich Metadaten wie Lizenz und Version. So kann ein Sicherheitsteam schnell die von einem Lieferkettenangriff betroffenen Komponenten identifizieren und patchen. 

Das NIST empfahl daraufhin, die SBOM-Praxis um eine kryptografische Stückliste (CBOM) zu erweitern, als Teil seiner Leitlinien für die Migration zur Post-Quanten-Kryptographie (PQC), insbesondere im Leitfaden SP 1800-38 des National Cybersecurity Center of Excellence des National Institute of Standards and Technology (NIST) . Diese Empfehlung wurde inzwischen formalisiert: CBOM ist nun integraler Bestandteil des OWASP CycloneDX Bill of Materials-Standards, der in Version 1.6 die Unterstützung kryptografischer Assets hinzufügte und als ECMA-424-Standard veröffentlicht ist.

Wichtige Erkenntnisse

• Ein CBOM ist ein strukturiertes Inventar von Algorithmen, Schlüsseln, Zertifikaten, Protokollen und kryptografischen Bibliotheken, standardisiert nach OWASP CycloneDX (jetzt veröffentlicht als ECMA-424).
• Im Gegensatz zu einem SBOM, das Softwarekomponenten auflistet, listet ein CBOM die Kryptografie auf, die diese Komponenten tatsächlich verwenden, und ist somit der Ausgangspunkt für die Planung der Post-Quanten-Migration.
• Der Entwurf des IR 8547-Zeitplans des NIST sieht vor, RSA, ECDSA, ECDH und Finite-Field Diffie-Hellman nach 2030 als veraltet zu betrachten und sie nach 2035 nicht mehr zuzulassen. Dieser Zeitplan wird nun für Systeme der Bundesregierung durch die Executive Order 14412 und das OMB-Memorandum M-26-15 unterstützt.
• Ein vollständiges CBOM-Programm geht über einen einmaligen Scan hinaus: Es klassifiziert Assets nach Risiko, wendet Zugriffskontrollen auf Schlüssel an, steuert den kryptografischen Lebenszyklus und ordnet die Ergebnisse Compliance-Rahmenwerken wie PCI DSS und DSGVO zu.
• Die CBOM-Tools haben echte Einschränkungen, darunter blinde Flecken bei der konfigurationsgesteuerten Kryptographie und älteren Binärdateien. Daher sollte man es als kontinuierliche Praxis und nicht als einmalige Prüfung betrachten.

Was ist eine kryptografische Stückliste (CBOM)? 

Eine kryptografische Stückliste (CBOM) ist ein maschinenlesbares Inventar, das alle kryptografischen Komponenten eines Systems katalogisiert: Algorithmen und deren Parameter (Schlüssellängen, Modi), Schlüssel, digitale Zertifikate, kryptografische Bibliotheken und die zugehörigen Protokolle. CBOM ist als Erweiterung des OWASP CycloneDX-Standards formalisiert, dem gleichen Full-Stack-Stücklistenformat, das auch für SBOM, SaaSBOM und Hardware-Stücklisten verwendet wird. Während eine SBOM angibt, welche Softwarekomponenten und -versionen ausgeführt werden, zeigt eine CBOM an, welche Kryptografie diese Komponenten tatsächlich verwenden – Informationen, die eine SBOM allein nicht erfasst.

CBOM vs. SBOM: Was ist der Unterschied?

Ein SBOM (Software-Based Object Model) erfasst Softwarekomponenten: Bibliotheken, Abhängigkeiten sowie deren Versionen und Lizenzen. Ein CBOM (Cryptography-Based Object Model) erfasst die Kryptografie innerhalb und um diese Komponenten herum. Beide ergänzen sich, und die PQC-Migrationsrichtlinien des NIST (National Institute of Standards and Technology) betrachten CBOM als Erweiterung der SBOM-Praxis und nicht als deren Ersatz.

Aspekt	SBOM	CBOM
Verfolgt	Softwarekomponenten, Versionen, Lizenzen	Algorithmen, Schlüssellängen, Zertifikate, Protokolle
Haupttreiber	Executive Order 14028 (2021), Lieferkettenrisiko	Post-Quanten-Migration, NIST PQC-Leitfaden
Standardformat	CycloneDX, SPDX	CycloneDX-Kryptographieerweiterung (ECMA-424)
Antworten	„Welche Software verwende ich?“	„Welche Verschlüsselungsmethode verwendet die Software, und ist sie quantensicher?“

Was sollte ein CBOM-Inventar enthalten? 

Ein vollständiges CBOM ergänzt ein Standard-SBOM-Inventar (Betriebssystem, Web-/Anwendungsserver, SSL/TLS-Bibliotheken wie OpenSSL, Konfiguration und Log-Management-Tools) um die spezifischen kryptografischen Details, auf die diese Komponenten angewiesen sind. In der Praxis bedeutet dies die Erfassung von sechs Asset-Kategorien.

Kategorie	Beispiele	Warum es wichtig ist
Algorithms	RSA, ECDSA, AES, SHA-2/SHA-3	Identifiziert, welche Algorithmen quantenanfällig bzw. quantensicher sind.
Tasten	Schlüsselgröße, Typ, Speicherort	Flaggen, die zu klein sind oder unsachgemäß gelagert wurden – Schlüsselmaterial
Zertifikate	X.509-Zertifikate, Ablaufdaten	Oberflächen, deren Zertifikate ablaufen oder schwach signiert sind, bevor sie einen Ausfall verursachen
Protokolle	TLS / SSL Versionen, SSH, VPN-Konfigurationen	Zeigt veraltete Protokollversionen auf, die noch immer im Einsatz sind.
Bibliotheken und Module	OpenSSL, BoringSSL, sprachnative Kryptobibliotheken	Verknüpft bekannte CVEs direkt mit den Systemen, die sie verwenden.
Hardware	HSMsIoT- und eingebettete Geräte	Erweitert die Transparenz über die Software hinaus auf die Hardware, die das Vertrauen verankert.

Aufbau eines kryptografischen Governance-Frameworks rund um Ihr CBOM

Ein CBOM ist nur so nützlich wie das darauf aufbauende Governance-Programm. Sobald Sie alle Algorithmen, Schlüssel und Zertifikate in Ihrer Umgebung kennen, müssen Sie entscheiden, wie mit jedem einzelnen umzugehen ist: Wie wird es klassifiziert? Werden die zugrunde liegenden Daten verschlüsselt oder tokenisiert? Wer hat Zugriff darauf? Wie wird sein Lebenszyklus verwaltet? Wie wird im Fehlerfall eine Wiederherstellung durchgeführt? Wie wird es zukünftig überwacht? Und wie wird es den geltenden Compliance-Rahmenbedingungen zugeordnet?

Kryptografische Vermögenswerte nach Risiko klassifizieren

Nicht jeder Eintrag in einem CBOM ist gleich dringlich. Die Klassifizierung bedeutet, jeden Algorithmus und Schlüssel hinsichtlich seiner Quantensicherheitslücke und der Sensibilität bzw. Aufbewahrungsdauer der geschützten Daten zu bewerten. So können Sie die Migration priorisieren, anstatt ein Inventar mit 5,000 Einträgen als statische Aufgabenliste zu behandeln.

Algorithmus oder Schlüsseltyp	NIST IR 8547 Entwurfsstatus	Empfohlene Aktion
RSA-2048, ECC P-256 (~112-Bit-Sicherheit)	Vorgeschlagene Funktion, die nach 2030 als veraltet gilt.	Planen Sie die Migration jetzt; priorisieren Sie Daten mit langer Vertraulichkeitsdauer.
RSA-3072, ECC P-384 (höherfeste Varianten)	Vorgeschlagene Maßnahme nach 2035 nicht mehr zulässig	Migration vor 2035; größere Schlüsselgrößen verschaffen Zeit, aber keine Befreiung.
ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Finalisierte NIST-Standards, August 2024	Zielalgorithmen für neue Bereitstellungen und Migration
AES-256, SHA-2, SHA-3	Nicht im Zeitplan für die Abschaffung öffentlicher Schlüssel gemäß IR 8547 enthalten.	Keine Zwangsmigration; wichtige Managementpraktiken weiterhin überprüfen.

NIST IR 8547 ist Mitte 2026 noch immer ein erster öffentlicher Entwurf. Die angegebenen Daten dienen daher eher als Orientierung denn als endgültige Regelung. Die Executive Order 14412 „Securing the Nation Against Advanced Cryptographic Attacks“ (unterzeichnet am 22. Juni 2026) und das OMB-Memorandum M-26-15 (erlassen am 24. Juni 2026) wandeln den in IR 8547 vorgesehenen Zeithorizont 2030 jedoch bereits in einen verbindlichen, fünfphasigen Migrationsplan für besonders wertvolle Bundesressourcen und Systeme mit hoher Auswirkung um. Die Migrationspläne der einzelnen Behörden sind bis Oktober 2026 einzureichen. Die Order definiert zudem die neue Rolle des „PQC Migration Lead“, der explizit für die behördenweite kryptografische Bestandsverwaltung zuständig ist – genau die Aufgabe, die ein CBOM (Cryptographic Inventory Management) erfüllt.

Wählen Sie zwischen Verschlüsselung und Tokenisierung.

Ihr CBOM zeigt Ihnen, wo sensible Daten mit einem bestimmten Algorithmus in Berührung kommen. Genau diese Information benötigen Sie, um die richtige Kontrollmaßnahme auszuwählen. Verwenden Sie Verschlüsselung, wenn die Anwendung den Originalwert wiederherstellen muss oder wenn Daten zwischen Systemen übertragen werden, die Sie nicht vollständig kontrollieren. Nutzen Sie Tokenisierung, wenn Sie sensible Werte (z. B. Zahlungskartennummern) vollständig aus einem System entfernen und dessen Compliance-Umfang reduzieren möchten. Ein Token hat nämlich keine mathematische Beziehung zum Originalwert und kann ohne den separaten Datenspeicher, der ihn ausgestellt hat, nicht rückgängig gemacht werden.

Zugriffskontrollen für Schlüssel und Zertifikate durchsetzen

Jeder Schlüssel und jedes Zertifikat, das Ihr CBOM bereitstellt, benötigt einen Eigentümer und eine Zugriffsrichtlinie. Das bedeutet: Trennung der Rollen von Schlüsselanforderern und -ausstellern, Speicherung in einem Hardware-Sicherheitsmodul statt in einfachen Dateien oder Quellcode sowie regelmäßige Aktualisierung der Zugangsdaten anstelle von Schlüsseln, die jahrelang unverändert bleiben. Ein CBOM ohne Zugriffsverwaltung dokumentiert das Problem lediglich, löst es aber nicht.

Den Lebenszyklus kryptografischer Vermögenswerte steuern

Jeder Eintrag in einem CBOM durchläuft einen Lebenszyklus: Ausstellung, Rotation, Verlängerung, Widerruf und Außerbetriebnahme. Governance bedeutet, festzulegen, wer welche Phase auslöst und wie diese protokolliert wird, sodass beispielsweise ein ablaufendes Zertifikat oder ein zur Außerbetriebnahme vorgesehener Algorithmus planmäßig gewartet wird, anstatt als Ausfall erfasst zu werden.

Planen Sie die Wiederherstellung, bevor Sie sie brauchen.

Ein CBOM (Critical Base Management Objective) identifiziert die Schlüssel und Zertifizierungsstellen, die für Ihr Unternehmen die größte Last tragen. Genau diese Liste benötigen Sie für Ihre Notfallwiederherstellungsplanung. Das bedeutet: Hinterlegung und Sicherung von Verschlüsselungsschlüsseln, ein dokumentierter Wiederherstellungspfad für den Fall, dass eine Zertifizierungsstelle kompromittiert oder nicht verfügbar ist, und regelmäßige Wiederherstellungstests – nicht nur eine Sicherung, die noch nie wiederhergestellt wurde.

Kontinuierliche Überwachung, nicht nur zum Zeitpunkt der Prüfung.

Eine einmal jährlich erstellte CBOM ist bereits am Tag der Veröffentlichung einer neuen Abhängigkeit veraltet. Kontinuierliche Überwachung bedeutet, dass bei jedem Build oder Deployment erneut gescannt wird, bei ablaufenden Zertifikaten vor Ausfallzeiten gewarnt wird und Abweichungen gemeldet werden, sobald neuer Code einen Algorithmus oder eine Schlüssellänge einführt, die außerhalb der genehmigten Baseline liegt.

Ergebnisse den Compliance-Anforderungen zuordnen

Ein aktuelles CBOM (Cryptography Based Outsourcing Model) dient als direkter Nachweis für die kryptografiebezogenen Kontrollen gemäß PCI DSS, HIPAA, DSGVO und ISO/IEC 27001 Anhang A und gewinnt auch für EU-spezifische Verpflichtungen zunehmend an Bedeutung: Sowohl der EU Cyber ​​Resilience Act als auch DORA (Delivery Office of Research) erhöhen den Druck auf eine nachweisbare, vollständige Transparenz der in Produkten und Systemen des Finanzsektors eingebetteten Kryptografie. Die Zuordnung jedes CBOM-Eintrags zu der jeweiligen Kontrolle, die er erfüllt, macht aus einer Inventarliste einen Prüfnachweis.

Wie man ein CBOM erstellt: Ein vierstufiger Prozess

Der Aufbau eines CBOM ist ein iterativer Prozess, keine einmalige Überprüfung. Diese vier Schritte umfassen die Ermittlung von der Analyse bis zur Automatisierung.

1. Entdecken Sie die kryptografischen Entitäten:

   Identifizieren Sie kryptografische Entitäten in Ihrem System: Anwendungen von Drittanbietern (Datenbanken, Konfigurationsmanagement- und Automatisierungstools), Quellcode, ruhende Daten (Konfigurationsdateien, digitale Zertifikate , Passwörter und Schlüssel), übertragene Daten ( SSL/TLS -Protokolle und VPN-Konfigurationen) sowie Hardware ( HSMs und IoT-Geräte).

2. Inventar erstellen und pflegen:

   Legen Sie fest, wann in jeder Entwicklungs- und Bereitstellungsphase ein Inventar erstellt werden soll. Jede Phase sollte die vorherige ergänzen und die Verbindung zwischen Einführungsort und Verwendungsort einer Komponente aufrechterhalten, um Schwachstellen nachverfolgen und beheben zu können. Unterschiedliche Stakeholder benötigen unterschiedliche Zuständigkeiten: Ein Produktteam konzentriert sich typischerweise auf Quellcode, Abhängigkeiten und Anwendungskonfiguration, während der IT-Betrieb einen umfassenderen Überblick benötigt, der Software, PKI , SaaS, Netzwerk, Daten und Hardware einschließt.

3. Regelmäßige Prüfungen und Überprüfungen:

   Planen Sie regelmäßige Audits ein, um zu bestätigen, dass kryptografische Einheiten noch den aktuellen Sicherheitsstandards entsprechen, und um Abweichungen frühzeitig zu erkennen: unsichere Schlüssellängen, schwache Algorithmen, Zertifikate, die erneuert oder widerrufen werden müssen.

4. Automatisieren und in CI/CD integrieren:

   Manuelle, punktuelle Scans sind für weniger Repositories nicht praktikabel. Open-Source-Tools, die auf dem CycloneDX CBOM-Schema basieren, können zusammen mit kommerziellen Scannern kryptografische Metadaten automatisch aus Quellcode, Containern und Infrastructure-as-Code-Vorlagen extrahieren. Die Integration der CBOM-Generierung in Ihre CI/CD-Pipeline wandelt sie von einer jährlichen Prüfung in ein dynamisches, versioniertes Artefakt um.

Wie verbessert CBOM Ihre Sicherheitslage? 

Ein CBOM (Cryptographic Asset Management) bietet Ihrem Unternehmen detaillierte Einblicke in die kryptografischen Assets, die mit jeder Ihrer kommerziellen und Open-Source-Komponenten verknüpft sind. Dies verbessert Ihre Sicherheitslage auf drei konkrete Arten: Erstens stärkt es Ihre Krypto-Agilität: Sie können proaktiv gegen Angriffe auf die Lieferkette vorgehen und im Falle eines Angriffs schneller reagieren, da Sie bereits wissen, welche Komponenten betroffen sind. Zweitens reduziert es die betrieblichen und finanziellen Folgen eines Sicherheitsvorfalls. Ohne CBOM ist die Identifizierung aller exponierten Assets nach einem Vorfall langsam und manuell, was mit hohen Kosten verbunden ist. Drittens unterstützt ein aktuelles CBOM-Inventar die Einhaltung regulatorischer Rahmenbedingungen wie NIST-Richtlinien, ISO 27001 und DSGVO.

Da ein CBOM (Cryptographic Assets Model) einen detaillierten Überblick über Ihre kryptografischen Assets bietet, dient es auch als Planungsgrundlage für die Migration von quantenanfälligen Algorithmen wie RSA , DSA, ECDSA und ECDH zu den NIST-standardisierten Post-Quanten-Algorithmen ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205), die alle im August 2024 finalisiert wurden. Eine Migration, die man nicht überblicken kann, lässt sich nicht planen – und ein CBOM macht diese Planung erst möglich.

Was sind die Grenzen eines CBOM? 

Ein CBOM ist ein notwendiges Werkzeug, aber keine Komplettlösung, und es lohnt sich, sich vorher genau zu überlegen, wo seine Grenzen liegen.

• Namensmehrdeutigkeit: Unterschiedliche Scan-Tools können denselben Algorithmus unter verschiedenen Namen oder Parametergruppen ausgeben, was den Vergleich zwischen den Tools erschwert.
• Konfigurationsgesteuerte Kryptographie: Die zur Laufzeit oder durch Konfiguration statt durch Code ausgewählten Verschlüsselungssuiten und Algorithmen sind allein durch statische Analyse schwerer zu erkennen.
• Angebot versus Verbrauch: Ein CBOM muss zwischen einer Komponente, die Kryptographie implementiert, und einer Komponente unterscheiden, die lediglich die Implementierung einer anderen Bibliothek aufruft, und diese Unterscheidung ist aus dem Quellcode nicht immer ersichtlich.
• Abdeckungslücken: Kompilierte Binärdateien, Firmware und Legacy-Systeme ohne Quellcodezugriff sind schwieriger zu scannen als moderne, quellcodeverfügbare Anwendungen.
• Das Snapshot-Problem: Ein CBOM ist nur zum Zeitpunkt seiner Erstellung korrekt. Ohne kontinuierliches Scannen veraltet es genauso schnell wie Ihre nächste Bereitstellung.

Ein Praxisbeispiel: Migration einer bestehenden Zertifizierungsstelle

So greifen die oben genannten Schritte in der Praxis ineinander: Ein CBOM-Scan einer internen Zertifizierungsstelle deckt mehrere tausend aktive Zertifikate auf, die noch mit 2048-Bit-RSA-Schlüsseln ausgestellt wurden. Ein Abgleich mit der obigen Klassifizierungstabelle zeigt, dass RSA-2048 gemäß dem Entwurf IR 8547 des NIST nach 2030 zur Abschaffung vorgesehen ist. Das Sicherheitsteam weist der Migration daher eine Priorität zu, basierend darauf, wie lange die geschützten Daten jedes Zertifikats vertraulich bleiben müssen. Zertifikate für langlebige Daten (signierte Firmware, Archivdatensätze) werden zuerst, kurzlebige, häufig rotierte Zertifikate zuletzt eingeplant. Anschließend verwendet das Team eine PKI-as-a-Service-Plattform, um Hybridzertifikate auszustellen, die die bestehende RSA-Signatur mit einer ML-DSA-Signatur kombinieren. So können vertrauende Parteien, die noch keine Post-Quanten-Algorithmen unterstützen, während der Umstellung weiterhin funktionieren. Nach jeder Migrationswelle wird der CBOM erneut gescannt, um zu bestätigen, dass die Anzahl der RSA-2048-Zertifikate tatsächlich sinkt und nicht nur davon auszugehen, dass der Plan auf Kurs ist.

Wie könnte eine Verschlüsselungsberatung helfen? 

CBOM Secure ist die kryptografische Erkennungs- und Inventarisierungsplattform von Encryption Consulting. Sie scannt Ihre Umgebung nach Algorithmen, Schlüsseln, Zertifikaten und Protokollen, erstellt ein CycloneDX-basiertes CBOM und hebt schwache oder quantenanfällige Kryptografie hervor, sodass Ihr Team die Migration anhand von Fakten statt durch Vermutungen priorisieren kann.

Sobald Ihr CBOM erstellt ist, wandeln die PQC Advisory Services von Encryption Consulting dieses Inventar in einen detaillierten Migrationsplan um: eine umfassende Risikoanalyse Ihrer On-Premises-, Cloud- und SaaS-Umgebungen, eine Strategie und ein Fahrplan zur Minderung der durch das CBOM offengelegten quantensicheren Kryptografie sowie praktische Unterstützung bei der Implementierung der Technologien und Prozesse, die Sie zu einer quantenresistenten Umgebung führen. Unsere Dienstleistungen basieren auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Weiterführende Informationen finden Sie unter: Wie ein kryptografisches Inventar eine umfassendere Krypto-Agilitätsstrategie unterstützt , worauf Käufer bei Post-Quantum-Ready-PKI-as-a-Service achten sollten und wo CBOM im fünfstufigen PQC-Reifegradmodell von Encryption Consulting einzuordnen ist.

Fazit

Die Identifizierung und Verwaltung der Software- und Kryptografie-Assets Ihres Unternehmens mittels SBOM bzw. CBOM bildet die Grundlage für die Abwehr von Angriffen auf die Software-Lieferkette und kryptografische Angriffe. Ein einmalig erstelltes und sich selbst überlassenes CBOM ist nur geringfügig besser als gar kein CBOM; der Nutzen ergibt sich erst durch die Kombination mit Klassifizierung, Zugriffskontrollen, Lebenszyklus-Governance, Wiederherstellungsplanung, kontinuierlicher Überwachung und Compliance-Mapping. Zudem muss es stets aktuell gehalten werden, wenn sich Ihre Systeme ändern und die Migrationsfristen nach der Quantenmigration näher rücken.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen einem CBOM und einem SBOM?

Eine Software-Stückliste (SBOM) listet die Softwarekomponenten, Bibliotheken und Abhängigkeiten einer Anwendung sowie Metadaten wie Version und Lizenz auf. Eine kryptografische Stückliste (CBOM) listet die von diesen Komponenten verwendeten kryptografischen Ressourcen auf: Algorithmen, Schlüssellängen, Zertifikate und Protokolle. Das NIST betrachtet die CBOM als Erweiterung der SBOM-Praxis speziell für die Migrationsplanung im Bereich der Post-Quanten-Kryptografie.

Welches Format sollte ein CBOM verwenden?

Das vorherrschende Format ist OWASP CycloneDX, das in Version 1.6 native Unterstützung für kryptografische Assets eingeführt hat und nun als ECMA-424-Standard veröffentlicht ist. Die Verwendung eines Standardformats anstelle einer proprietären Tabellenkalkulation gewährleistet, dass Ihr CBOM mit dem wachsenden Ökosystem von Open-Source- und kommerziellen CycloneDX-Tools kompatibel ist.

Wer ist innerhalb einer Organisation für die Pflege eines CBOM verantwortlich?

Die Verantwortlichkeiten sind üblicherweise nach Umfang aufgeteilt: Produkt- und Anwendungssicherheitsteams verwalten das CBOM für Quellcode und Anwendungsabhängigkeiten, während der IT-Betrieb oder eine dedizierte kryptografische Governance-Funktion das umfassendere Inventar in PKI, Netzwerk, Cloud und Hardware verwaltet. Bundesbehörden formalisieren dies nun mit der Executive Order 14412, die eine benannte Rolle des PQC-Migrationsleiters geschaffen hat, der für die behördenweite kryptografische Inventarverwaltung verantwortlich ist.

Wie unterstützt ein CBOM die Migration zur Post-Quanten-Kryptographie?

Ein CBOM identifiziert präzise, ​​wo quantenanfällige Algorithmen wie RSA und ECDSA eingesetzt werden. Dadurch lässt sich die Migration nach Datensensibilität und Aufbewahrungsdauer priorisieren, anstatt Systeme in beliebiger Reihenfolge zu migrieren. Diese Priorisierung ermöglicht die Einhaltung von Fristen wie dem NIST-Entwurf für die Abschaffung klassischer Public-Key-Algorithmen im Jahr 2030 und dem Verbot im Jahr 2035.

Lässt sich ein CBOM automatisieren oder sind manuelle Audits erforderlich?

Beides. Automatisierte Tools, die auf dem CycloneDX CBOM-Schema basieren, können kryptografische Metadaten aus Quellcode, Containern und Infrastructure-as-Code-Vorlagen im Rahmen einer CI/CD-Pipeline extrahieren und so den Bestand aktuell halten. Regelmäßige manuelle Prüfungen sind weiterhin wichtig, um konfigurationsbasierte Kryptografie und Legacy-Systeme zu erkennen, die von automatisierten Scannern nicht vollständig erfasst werden können.