TL;DR: CBOM Lens 1.1.0 gibt das CycloneDX-1.7-Kryptografieregister aus. Soweit wir wissen, ist es der erste CBOM-Producer, der dies tut. Außerdem wurden ein Windows-Registry-Scanner und vollständig offline arbeitende Schemavalidierung ergänzt.

Bei einer geschlossenen Aufzählung macht ein einziger falscher Wert das gesamte Dokument ungültig. Daher lässt CBOM Lens Werte weg, die es nicht belegen kann, statt zu raten, nur um vollständig zu wirken.

Eine Cryptographic Bill of Materials ist nur so nützlich, wie sie vertrauenswürdig ist. Meldet das Inventar beispielsweise eine bestimmte Kurve, während ein Dienst tatsächlich eine andere verwendet, ist jeder darauf aufbauende Migrationsplan falsch. Deshalb ist bei einem CBOM-Tool nicht die interessante Frage, wie viel es meldet. Entscheidend ist vielmehr, wie es sich verhält, wenn es etwas nicht weiß.

CycloneDX 1.7 hat diese Frage verschärft. CycloneDX ergänzte zwei registergestützte Felder zu algorithmProperties: algorithmFamily und ellipticCurve. Beide sind geschlossene Aufzählungen — 93 Familien und 246 Kurven. Ein Wert außerhalb des Vokabulars verschlechtert ein Dokument daher nicht nur; er macht es ungültig.

CBOM Lens 1.1.0 schreibt beide Felder. Soweit wir feststellen können, ist es der erste CBOM-Producer, der das Kryptografieregister von 1.7 ausgibt. Die Belege für diese Aussage stehen im Anhang zur Registerübernahme des Repositorys – einschließlich einer Methode, um sie zu widerlegen. Falls Sie einen früheren Producer kennen, möchten wir davon erfahren.

Warum das Register die Disziplin verändert

Vor 1.7 waren die Familie und die Kurve eines Algorithmus Freitext. Ein Producer konnte beliebige Werte schreiben und trotzdem schemakonform bleiben. Dokumente ließen sich dadurch leicht erzeugen, aber schwer vergleichen. Zwei Tools konnten denselben Schlüssel beispielsweise auf drei verschiedene Arten beschreiben.

Registergestützte Felder lösen das Vergleichsproblem. Gleichzeitig erhöhen sie die Kosten eines Fehlers. Ein Producer, der einen gescannten String ungeprüft weitergibt, wird irgendwann einen Wert außerhalb des zulässigen Vokabulars ausgeben. Dann schlägt die Validierung des gesamten Dokuments fehl.

CBOM Lens arbeitet deshalb mit vollständigen Mapping-Tabellen und lässt einen Wert bei fehlender Zuordnung weg. Nichts wird ungeprüft durchgereicht. In der Praxis bleiben manche Felder leer, wo ein weniger sorgfältiges Tool einen Wert anzeigen würde. Wir halten das dennoch für den richtigen Kompromiss.

Das deutlichste Beispiel sind Kurven, die nur abgeleitet werden könnten. Nehmen wir eine Kurve, die aus einem Signature Digest geraten oder von einem anderen Zertifikat am selben Port übernommen wird. Beides klingt plausibel und bleibt dennoch bewusst ohne Zuordnung. Beide Vermutungen sind plausibel. Keine davon ist ein Beleg.

Post-Quantum-Algorithmen werden erkannt, nicht angenommen

Dieselbe Disziplin gilt für Post-Quantum-Berichte. Gerade dort ist die Versuchung für Inventarisierungswerkzeuge am größten, mehr Sicherheit vorzugeben als vorhanden.

CBOM Lens erkennt sechs Familien anhand ihrer Object Identifiers. Es handelt sich um ML-DSA (FIPS 204), SLH-DSA (FIPS 205, alle zwölf Parametersätze), ML-KEM (FIPS 203), XMSS, XMSS-MT und HSS-LMS. Für jede werden Schlüsselgrößen, Signaturgrößen und NIST-Sicherheitskategorien aus den Standards übernommen. Zudem steht die Quellenangabe direkt neben dem Wert im Quellcode.

Zwei Auslassungen zeigen, dass diese Regel funktioniert. Stateful hash-based signatures erhalten kein Quantum Security Level, weil SP 800-208 ihnen keines zuweist. HQC und FN-DSA werden überhaupt nicht behauptet, weil ihnen noch kein Object Identifier zugewiesen wurde. Ein Tool, das sie trotzdem meldet, würde eine Erkennung erfinden.

Wo keine maßgebliche Quelle existiert, wird das Feld weggelassen, statt etwas zu erfinden.

Was außerdem in 1.1.0 enthalten ist

Zwei weitere Änderungen sind operativ wichtig.

Erstens: ein Windows-Registry-Scanner. Die Scanner für Dateisystem, Container und Netzwerk deckten Linux-Umgebungen bereits gut ab. Unter Windows liegt kryptografische Konfiguration jedoch häufig in der Registry statt in Dateien. Deren Scan schließt eine echte Transparenzlücke in gemischten Umgebungen.

Zweitens ist die Validierung jetzt vollständig offline und strikt. Die SPDX- und JSF-Unterschemata sind eingebettet, sodass ein Dokument ohne Netzwerkzugriff validiert werden kann. Das ist für Scans in Air-Gapped-Umgebungen wichtig. Zugleich entfällt ein Fehlerfall, bei dem die Validierung unbemerkt schlechter wurde, weil ein entferntes Schema nicht erreichbar war.

Funktion Details
Scan-Ziele Dateisystem, Container-Images aus Docker oder Podman, Netzwerkports über nmap mit TLS- und SSH-Erkennung und jetzt auch die Windows Registry
Ausgabe CycloneDX CBOM 1.6 oder 1.7; 1.6 bleibt Standard- und Kompatibilitätsformat
Korrelation Inhaltsbasierte bom-ref-Bezeichner, sodass dasselbe Asset über verschiedene Quellen hinweg übereinstimmt
Betriebsmodi Einmalige manuelle Läufe, Timer-Modus mit cron- oder ISO-8601-Dauern und von ILM Core verwaltete Discovery
Ziel Optionaler Upload in ein CBOM Repository oder Nutzung durch eine andere Anwendung
Funktionen von CBOM Lens ab Version 1.1.0.

Die Auswahl von 1.7 ist eine Konfigurationsänderung: Setzen Sie die CBOM-Version auf 1.7. Da 1.6 weiterhin Standard bleibt, ändert ein Upgrade des Tools Ihr Ausgabeformat erst dann, wenn Sie dies ausdrücklich anfordern.

Wie dies zu ILM passt

CBOM Lens erzeugt das Inventar. Ein CBOM Repository speichert und durchsucht es. ILM nutzt es. Denn ein Inventar wird erst dann handlungsrelevant, wenn es neben den Zertifikaten und Schlüsseln steht, die es beschreibt.

Beide Tools sind Open Source und funktionieren unabhängig voneinander. Sie können CBOM Lens allein ausführen, auf ein Repository richten und den Rest der Plattform niemals verwenden. Dennoch ist es die Kombination, durch die ein Inventar aufhört, nur ein Bericht zu sein, und beginnt, Entscheidungen zu steuern.

Wir veröffentlichen dies teils, um Aufmerksamkeit zu schaffen, und teils, um Prüfung einzuladen. Das 1.7-Register ist neu und die Nutzung noch gering. Eine geschlossene Aufzählung belohnt außerdem sorgfältige Tools und bestraft selbstsichere. Wenn Sie einen CBOM-Producer bauen, lohnt es sich, über Mapping-Tabellen und Auslassungsregeln zu diskutieren.

Wichtigste Erkenntnisse

  • CBOM Lens 1.1.0 gibt die CycloneDX-1.7-Kryptografieregisterfelder algorithmFamily und ellipticCurve aus.
  • Beide Felder sind geschlossene Aufzählungen mit 93 Familien und 246 Kurven, bei denen ein falscher Wert das gesamte Dokument ungültig macht.
  • Werte werden über vollständige Mapping-Tabellen zugeordnet und bei fehlender Zuordnung weggelassen; abgeleitete Kurven bleiben bewusst ohne Mapping.
  • Sechs Post-Quantum-Familien werden anhand ihrer OIDs erkannt; Quellen aus Standards sind im Quellcode dokumentiert.
  • 1.1.0 ergänzt außerdem einen Windows-Registry-Scanner und vollständig offline arbeitende, strikte Schemavalidierung.

Sie beginnen bei null? Lesen Sie zuerst Aufbau eines umfassenden kryptografischen Asset-Inventars. Sehen Sie außerdem 10 Dinge, die Sie mit ILM aufbauen können. Für einen breiteren Blick auf Governance-Reife lesen Sie das PKI Maturity Model. Fragen zu einem Scan Ihrer eigenen Umgebung? Sprechen Sie mit uns.