CBOM Lens Emits the CycloneDX 1.7 Crypto Registry

TL;DR: CBOM Lens 1.1.0 emits the CycloneDX 1.7 cryptography registry. As far as we know, it is the first CBOM producer to do so. It also gained a Windows registry scanner and fully offline schema validation.

A cryptographic bill of materials is only as useful as it is trustworthy. Say the inventory reports one curve where a service actually uses another. Therefore any migration plan built on it is wrong. So the interesting question about a CBOM tool is not how much it reports. Instead, it is how the tool behaves when it does not know.

CycloneDX 1.7 made that question sharper. CycloneDX added two registry-backed fields to algorithmProperties: algorithmFamily and ellipticCurve. Both are closed enumerations — 93 families and 246 curves. Consequently one out-of-vocabulary value does not degrade a document; it invalidates it.

CBOM Lens 1.1.0 writes both fields. As far as we can establish, it is the first CBOM producer to emit the 1.7 cryptography registry. The evidence for that claim sits in the repository’s registry adoption appendix, together with the method for disproving it. And if you find an earlier producer, we would like to know.

Why the registry changes the discipline

Before 1.7, an algorithm’s family and curve were free text. A producer could write anything and remain schema-valid. That made documents easy to generate but hard to compare. For example, two tools could describe the same key three different ways.

Registry-backed fields fix the comparison problem. However, they also raise the cost of being wrong. A producer that passes a scanned string straight through will eventually emit a value outside the vocabulary. Consequently the whole document fails validation.

CBOM Lens therefore maps through total tables and omits on a miss. Nothing is passed through unchecked. In practice some fields stay empty where a less careful tool would show a value. Still, we consider that the correct trade.

The clearest example involves curves that could only be inferred. Take a curve guessed from a signature digest, or borrowed from another certificate on the same port. Both are plausible, and both are deliberately left unmapped. Both guesses are plausible. Neither is evidence.

Post-quantum algorithms are detected, not assumed

The same discipline governs post-quantum reporting. Specifically, that is where inventory tools are most tempted to overstate.

CBOM Lens recognises six families from their object identifiers. They are ML-DSA (FIPS 204), SLH-DSA (FIPS 205, all twelve parameter sets), ML-KEM (FIPS 203), XMSS, XMSS-MT, and HSS-LMS. Each carries key sizes, signature sizes, and NIST security categories transcribed from the standards. Also, the citation sits next to the value in the source.

Two omissions show the rule working. Stateful hash-based signatures carry no quantum security level, because SP 800-208 assigns them none. And HQC and FN-DSA are not claimed at all, because no object identifier has been assigned to them yet. A tool that reported them anyway would be inventing detection.

Where no authoritative source exists, the field is omitted rather than invented.

What else landed in 1.1.0

Two further changes matter operationally.

First, a Windows registry scanner. The filesystem, container, and network scanners already covered a Linux estate well. However, Windows cryptographic configuration often lives in the registry rather than in files. Scanning it closes a real visibility gap for mixed environments.

Second, validation is now fully offline and strict. The SPDX and JSF subschemas are embedded, so a document validates without network access. That matters for air-gapped scanning. It also removes a failure mode where validation quietly degrades because a remote schema was unreachable.

Capability	Detail
Scan targets	Filesystem, container images from Docker or Podman, network ports via nmap with TLS and SSH detection, and now the Windows registry
Output	CycloneDX CBOM 1.6 or 1.7; 1.6 remains the default and the compatibility format
Correlation	Content-based bom-ref identifiers, so the same asset matches across sources
Operating modes	One-shot manual runs, timer mode with cron or ISO-8601 durations, and discovery managed by ILM Core
Destination	Optional upload to a CBOM Repository, or consumption by another application

Selecting 1.7 is a configuration change: set the CBOM version to 1.7. Because 1.6 stays the default, upgrading the tool does not change your output format until you ask it to.

Where this fits with ILM

CBOM Lens produces inventory. A CBOM Repository stores and searches it. ILM consumes it. Because an inventory only becomes actionable next to the certificates and keys it describes.

Both tools are open source and both work independently. Run CBOM Lens on its own, point it at a repository, and never touch the rest of the platform. Still, the combination is where the inventory stops being a report and starts driving decisions.

We are publishing this partly to raise awareness and partly to invite scrutiny. The 1.7 registry is new and adoption is thin. Moreover, a closed enumeration rewards careful tools and punishes confident ones. If you are building a CBOM producer, the mapping tables and the omission rules are worth arguing about.

---

Starting from zero? Read building a comprehensive cryptographic asset inventory first. Finally, see 10 things you can build with ILM. For a wider view of governance maturity, see the PKI Maturity Model. Questions about a scan of your own estate? Talk to us.