Die Cryptographic Bill of Materials (CBOM): Was SBOM-Teams wissen müssen
| Interlynk
Eine CBOM inventarisiert die Kryptografie in Ihrer Software. Die Executive Order 14412 hat dafür gerade eine Frist gesetzt, und Teams, die bereits ein SBOM-Programm betreiben, haben den Großteil der Grundlage schon gelegt.
Übersicht
Ein neuer Begriff taucht bald auf vielen Security-Roadmaps auf: die Cryptographic Bill of Materials, oder CBOM. Eine US-Executive-Order hat ihn im Juni 2026 ausdrücklich benannt und eine Frist für die zugehörige Bundes-Guidance gesetzt. Falls Ihr erster Gedanke ist, dass das nach einem weiteren, bei null beginnenden Inventar klingt, hier das Nützliche vorweg: Ist es nicht. Eine CBOM ist die nächste Schicht auf dem Standard, den Ihre SBOMs bereits nutzen.
Dieser Leitfaden behandelt, was eine CBOM ist, wie sie sich von einer SBOM unterscheidet, wo die Executive Order einzuordnen ist und was Sie jetzt tun können, ohne auf die endgültigen Regeln zu warten.
CBOM im Überblick
Eine Cryptographic Bill of Materials ist ein maschinenlesbares Inventar der kryptografischen Assets in einer Software oder einem System: die verwendeten Algorithmen, ihre Schlüssellängen und Modi, die Bibliotheken, die sie implementieren, die Zertifikate und Schlüssel sowie die Protokolle, die darauf aufbauen. Eine SBOM beantwortet, welche Komponenten in Ihrer Software stecken. Eine CBOM beantwortet eine engere Frage darüber hinaus: welche Kryptografie diese Komponenten verwenden und ob ein Teil davon quantenanfällig ist. Die Executive Order 14412, unterzeichnet am 22. Juni 2026, weist CISA und NIST an, Mindestanforderungen für eine CBOM zu veröffentlichen, und CycloneDX, derselbe Standard, der Ihre SBOM trägt, unterstützt sie bereits.
Rechtsgrundlage: Executive Order 14412
Am 22. Juni 2026 unterzeichnete das Weiße Haus die Executive Order 14412, „Securing the Nation Against Advanced Cryptographic Attacks", drei Tage später im Federal Register veröffentlicht. Die Order beschleunigt den föderalen Umstieg auf Post-Quantum-Kryptografie und benennt zum ersten Mal in der US-Politik die Cryptographic Bill of Materials als Teil dieser Arbeit.
Drei Daten sind festzuhalten. CISA hat, gemeinsam mit NIST, 270 Tage ab der Order Zeit, Guidance zu den Mindestanforderungen für eine CBOM zu veröffentlichen, womit diese Guidance Anfang 2027 fällig wird. Bundesbehörden haben bis zum 31. Dezember 2030 Zeit, High-Value-Assets und High-Impact-Systeme auf Post-Quantum-Schlüsselaustausch umzustellen, und bis zum 31. Dezember 2031 für Post-Quantum-Signaturen. Eine vorgeschlagene Regelung der Federal Acquisition Regulation weitet die zugrunde liegenden Post-Quantum-Anforderungen auf betroffene Bundesauftragnehmer aus.
Auf dem Papier gilt die Order für US-Bundesbehörden. In der Praxis reicht sie weiter. Verkaufen Sie Software an die Regierung oder an ein Unternehmen, das das tut, folgen Ihnen die Auftragnehmer-Anforderungen über die Lieferkette. Erwartungen an kryptografische Inventare wandern zudem gern aus der Bundespolitik in regulierte Branchen, genau so, wie sich SBOM-Anforderungen nach der Executive Order 14028 von 2021 durch Gesundheitswesen, Finanzsektor und kritische Infrastruktur verbreitet haben.
SBOM vs CBOM
Eine SBOM und eine CBOM beschreiben dieselbe Software aus zwei verschiedenen Blickwinkeln.
Eine SBOM ist ein Komponenteninventar. Sie listet die Bibliotheken, Frameworks und Abhängigkeiten auf, aus denen eine Anwendung aufgebaut ist, mit Versionen und Identifikatoren, damit Sie Komponenten mit bekannten Schwachstellen und Lizenzbedingungen abgleichen können.
Eine CBOM zoomt auf eine Eigenschaft dieser Komponenten: die Kryptografie, die sie verwenden. Sie erfasst, welche Algorithmen, mit welchen Schlüssellängen, über welche Bibliotheken und Protokolle. Und sie ist für eine andere Aufgabe gebaut. Eine SBOM speist Schwachstellenmanagement und Compliance. Eine CBOM speist kryptografische Agilität, die Fähigkeit, schwache oder quantenanfällige Kryptografie zu finden und auszutauschen, bevor sie zum Problem wird.
Sie ergänzen sich. Eine SBOM sagt Ihnen, dass eine Komponente vorhanden ist. Eine CBOM sagt Ihnen, dass diese Komponente auf RSA-2048 setzt, das ein leistungsfähiger Quantencomputer irgendwann brechen würde. Sie brauchen das Erste, um das Zweite aufzubauen, und deshalb ist ein Team mit einer funktionierenden SBOM-Praxis bereits auf halbem Weg.
Ein Standard, zwei Schichten
Das Detail, das dies von einem Projekt bei null unterscheidet: Eine CBOM ist kein neues Dateiformat und kein konkurrierender Standard. Sie ist eine Erweiterung von CycloneDX, derselben Spezifikation, die viele Teams bereits für SBOMs nutzen.
Die CBOM-Unterstützung stammt aus der IBM-Forschung und kam mit CycloneDX Version 1.6 heraus, veröffentlicht im April 2024 und im Juni desselben Jahres als internationaler Standard ECMA-424, 1. Ausgabe, ratifiziert. Version 1.7, veröffentlicht im Oktober 2025 und als ECMA-424, 2. Ausgabe, angenommen, erweiterte sie um standardisierte kryptografische Algorithmusfamilien und Referenzen zu elliptischen Kurven für Post-Quantum-Readiness.
Technisch behandelt eine CBOM jedes kryptografische Asset als Komponente im CycloneDX-Schema und ergänzt den Abhängigkeitsgraphen um „uses"- und „implements"-Beziehungen. So lässt sich eine Kette ausdrücken: Eine Anwendung nutzt ein Protokoll, das Protokoll setzt auf einen Algorithmus, eine Bibliothek implementiert ihn. Weil sie in CycloneDX lebt, funktioniert eine CBOM mit dem Tooling, auf das Ihr SBOM-Workflow bereits angewiesen ist. Wenn Sie heute CycloneDX-SBOMs erzeugen, betreiben Sie bereits den Standard, in dem eine CBOM geschrieben ist. Einen Auffrischer dazu, wie CycloneDX gegenüber dem anderen wichtigen Format abschneidet, finden Sie in unserem Leitfaden CycloneDX vs SPDX.
Wer sich jetzt kümmern sollte
Die Order ist föderal. Die Zielgruppe ist größer.
Bundesauftragnehmer und -unterauftragnehmer spüren sie zuerst. Zwischen der vorgeschlagenen FAR-Regelung und dem Beschaffungsdruck, den die Order erzeugt, bewegen sich Post-Quantum-Anforderungen, und das kryptografische Inventar dahinter, auf jeden zu, der Software an die Regierung verkauft.
Regulierte Branchen sind als Nächstes dran. Gesundheitswesen, Finanzdienstleistungen und Energie tragen bereits kryptografische Pflichten, und sie standen nach 2021 als Erste in der Reihe, um SBOM-Erwartungen zu erben. Der Ablauf ist inzwischen vertraut: Eine Anforderung beginnt in der Bundespolitik, verfestigt sich in Beschaffungssprache und taucht dann in Branchenregulierung auf. Teams in Medizinprodukten, Industriesystemen und kritischer Infrastruktur haben guten Grund, das Inventar aufzubauen, bevor es von ihnen verlangt wird.
Für alle anderen gilt es als früher Hinweis darauf, wohin die Reise geht. Kryptografische Agilität wird zu einer schlichten Erwartung an sichere Software, mit oder ohne Regulierung, und das Inventar ist das, was sie möglich macht.
Harvest Now, Decrypt Later
Der Grund, Kryptografie schon jetzt zu inventarisieren, Jahre bevor es einen großen Quantencomputer gibt, hat einen Namen: Harvest now, decrypt later. Ein Angreifer kopiert heute verschlüsselte Daten, hebt sie auf und entschlüsselt sie, sobald Quantenfähigkeit verfügbar ist. Für alles mit langer Vertraulichkeitsdauer, Patientenakten, Finanzdaten, Staatsgeheimnisse, Verteidigungsentwürfe, hat die Uhr bereits zu laufen begonnen. Die heute abgegriffenen Daten sind an dem Tag noch sensibel, an dem die Kryptografie, die sie schützt, gebrochen werden kann.
Deshalb ist kryptografisches Inventar zeitkritisch und nicht Routine. Sie können nicht migrieren, was Sie nicht sehen, und die Migration muss weit fortgeschritten sein, bevor Quantenfähigkeit eintrifft, statt danach hektisch zu beginnen.
Vom Inventar zur Readiness
Eine CBOM ist der erste Schritt zur Post-Quantum-Readiness, und sie bringt Sie nicht den ganzen Weg. Ein Inventar zeigt, wo Kryptografie steckt. Readiness bedeutet zu wissen, welche davon am wichtigsten ist, wie schwer sich jedes Stück ersetzen lässt, womit es interoperiert und in welcher Reihenfolge geändert werden sollte. Kartieren und Migrieren sind verschiedene Aufgaben.
Doch das Inventar macht den Rest erst möglich. Kryptografie versteckt sich tief in Komponenten, Protokollen und Bibliotheken, oft mehrere Schichten tief, genau dort, wo SBOM-Tooling ohnehin schon hinschaut. Eine CBOM holt diesen verborgenen kryptografischen Fußabdruck in etwas, das ein Tool lesen, priorisieren und über die Zeit verfolgen kann, während sich die Software ändert. Lassen Sie es weg, und eine Post-Quantum-Migration ist größtenteils Raterei.
Praktische erste Schritte
Sie brauchen die endgültige CISA- und NIST-Guidance nicht, um anzufangen. Die Mindestanforderungen werden das Format ordnen. Sie werden die grundlegende Arbeit, die eigene Kryptografie zu sehen, nicht verändern.
Inventarisieren Sie Ihren kryptografischen Fußabdruck. Finden Sie die Algorithmen, Schlüssellängen, Bibliotheken, Zertifikate und Protokolle im Einsatz über Ihre Produkte hinweg, auf dieselbe build-bewusste Weise, wie Sie bereits SBOMs erzeugen.
Markieren Sie die quantenanfälligen Stücke. RSA, Elliptic-Curve-Kryptografie, Diffie-Hellman und alte Hashes wie MD5 und SHA-1 tauchen zuerst auf. Zu wissen, wo sie sitzen, ist der ganze Sinn.
Nutzen Sie den Standard, den Sie schon betreiben. Erzeugen Sie die CBOM in CycloneDX, damit sie neben Ihren SBOMs lebt und in Ihr vorhandenes Tooling passt, statt in einer einmaligen Tabelle.
Priorisieren Sie nach Datenlebensdauer. Langlebige sensible Daten sind das Harvest-now-Ziel. Beginnen Sie dort, wo das Vertraulichkeitsfenster am längsten ist.
Halten Sie sie aktuell. Wie eine SBOM ist eine CBOM nur dann etwas wert, wenn sie dem entspricht, was Sie tatsächlich ausliefern. Erzeugen Sie sie neu, während sich der Code ändert.
Fazit
Die Executive Order 14412 nahm das kryptografische Inventar, das reife Teams nach eigenem Zeitplan pflegten, und hängte ihm eine föderale Frist an. Die Mindestanforderungen werden noch geschrieben, aber die Richtung steht, und sie folgt der SBOM-Geschichte eng genug, dass die Lehre auf der Hand liegt.
Ein Team, das bereits ein SBOM-Programm betreibt, beginnt nicht bei null. Sie haben das Tooling, den Standard und die build-bewusste Erkennung, auf die eine CBOM baut. Die nächste Schicht ist kryptografische Sichtbarkeit, und die Teams, die sie jetzt hinzufügen, sind bereit, wenn die Guidance eintrifft und die Beschaffungssprache nachzieht.
Interlynk hilft Teams, maschinenlesbare Inventare dessen zu erstellen und zu pflegen, woraus ihre Software besteht, in CycloneDX und SPDX, über den gesamten Produktlebenszyklus. Da kryptografische Transparenz Teil derselben Diskussion wird, ist die Grundlage dieselbe, die Sie ohnehin für SBOMs brauchen: genaue, build-bewusste, kontinuierlich aktualisierte Komponentensichtbarkeit. Siehe unsere Lösung für den Cyber Resilience Act oder buchen Sie eine Demo, um zu besprechen, wo SBOM und kryptografisches Inventar zusammentreffen.
Demo buchen · Kostenlos starten
Dieser Leitfaden gibt die Executive Order 14412 und öffentlich verfügbare CycloneDX- und NIST-Materialien wieder und wurde zum Zeitpunkt der Veröffentlichung auf Richtigkeit geprüft. Die CBOM-Mindestanforderungen von CISA und NIST stehen noch aus und können diese Details verfeinern. Bestätigen Sie aktuelle Anforderungen anhand offizieller CISA-, NIST- und CycloneDX-Quellen. Dieser Artikel dient der Information und stellt keine Rechtsberatung dar.
Referenzen
Executive Order 14412, „Securing the Nation Against Advanced Cryptographic Attacks" (Federal Register): https://www.federalregister.gov/
CycloneDX v1.6 Release, CBOM eingeführt: https://cyclonedx.org/news/cyclonedx-v1.6-released/
CycloneDX v1.7 Release, erweiterte CBOM: https://cyclonedx.org/news/cyclonedx-v1.7-released/
NIST Post-Quantum Cryptography Projekt: https://csrc.nist.gov/projects/post-quantum-cryptography