You cannot migrate what you cannot see: build a CBOM with qScan

Ask a team where their RSA and elliptic-curve cryptography lives and you usually get a confident, incomplete answer: the TLS termination, the obvious signing key. Then a scan finds it in a vendored library, a container base image, an old JWT helper, a code-signing step in CI, a database driver's default. The gap between what an organization believes it runs and what it actually runs is where post-quantum migrations stall. Every framework, NIST's included, opens with the same instruction: inventory first. A CBOM is that inventory, written down in a form other tools can read.

What a CBOM actually is

A CBOM (cryptographic bill of materials) is a CycloneDX 1.6 document that lists cryptographic assets the way a software bill of materials lists packages: one component per distinct algorithm, with its primitive, parameters, and where it was found. It is a standard, so it travels: a CBOM your scanner emits can be read by another vendor's tool, attached to a compliance record, or diffed against last month's to see what changed. It answers one question precisely, what cryptography is present and where, which is the question every later decision depends on.

Generate one in about a minute

qScan is our open-source scanner. Point it at a repository and ask for the CBOM format:

npx @quantakrypto/qscan ./ --cbom -o qscan-cbom.json

That walks the tree, runs the detector registry across source (14 languages), dependencies (7 ecosystems), and infrastructure and configuration (35 surfaces, from TLS and SSH config to container images and IaC), and writes a single CycloneDX 1.6 CBOM. `--cbom` is an alias for `--format cbom`; the same scan can also emit SARIF for code-scanning, OpenVEX, ISO 27001 A.8.24 evidence, or plain JSON. No key material, source, or secret goes into the file: a CBOM names algorithms and locations, not the crypto itself.

Code and infrastructure in one bill

The cryptography that will hurt you is rarely all in the source tree. qScan can merge an externally produced CBOM into its own, so a bill of materials from a live-endpoint probe (what a server actually negotiates) folds into the code-and-config inventory under CycloneDX's own merge rules:

npx @quantakrypto/qscan ./ --cbom --merge qprobe-cbom.json -o combined-cbom.json

The result is one document that spans what your code declares and what your systems actually do at runtime, which is the inventory a migration plan is built on.

What to do with it

• Prioritize by risk, not by count: rank the inventory by data lifetime and harvest-now-decrypt-later exposure, so the same RSA key is urgent behind long-lived records and trivial on a brochure page.
• Gate it in CI: fail a build when a new quantum-vulnerable component appears that was not in the baseline, so the inventory never silently grows.
• Give it to an agent: the quantakrypto MCP server exposes a CBOM tool, so an AI coding agent can request the inventory and reason about it in natural language.
• Summarize it publicly: the CBOM summary is one field of a crypto-agility.json manifest, so the detail stays private while the shape of your posture can be published.

The point

A migration is a sequence of decisions, and every one of them, what to replace, in what order, by when, is only as good as the inventory underneath it. The reason to produce a CBOM early is not the document; it is that the act of producing it is usually the first time anyone sees the whole cryptographic estate at once. Run it before you plan, and run it again on every build so the map never goes stale.

References

• qScan - the open-source scanner and CBOM emitter.
• CycloneDX Cryptography Bill of Materials (CBOM) - the 1.6 format qScan emits.
• Cryptographic inventory guide - the longer method behind this how-to.
• crypto-agility.json - publishing a summary of the inventory at a well-known URL.