Cryptographic bills of material

A cryptographic bill of materials is an inventory of the cryptography a system uses, in a machine-readable form, with enough provenance that somebody else can check it. It is the natural export format for a discovery run, and it is the artefact most likely to be asked for by a regulator or a customer's procurement team over the next few years.

#What a CBOM is

The idea is borrowed directly from software supply-chain work. A software bill of materials answers which components are in this system. A CBOM answers a narrower question: which cryptographic primitives are in use, where, in what role, and with what parameters.

The unit of a CBOM is a cryptographic asset, and that word has to mean something precise or the document is decorative. Ours uses the definition in What counts as an asset: one cryptographic use at one location, with a surface, a primitive, a role and a stable fingerprint. Every row in an exported CBOM corresponds to exactly one asset in the inventory the export was generated from.

Scope

One estate, one discovery run, one point in time. A CBOM is a snapshot, not a live feed.

Unit

One cryptographic asset, as defined by the asset model.

Provenance

Each entry names the detector and version that produced its evidence, and its confidence.

Coverage

The surfaces collected and the surfaces skipped, carried in the document rather than in a covering email.

Not included

Key material, ciphertext, secrets, and any content of an encrypted object.

#How it relates to an SBOM

An SBOM and a CBOM overlap without either containing the other. An SBOM will tell you that a service depends on a particular TLS library at a particular version. That is genuinely useful, and our source.dependency-graph detector reads exactly that data. It is not sufficient, for two reasons.

First, the presence of a library says nothing about which of its algorithms a system actually calls. A library that supports both a quantum-vulnerable key exchange and a standardised post-quantum one appears identically in an SBOM in either case. Second, a great deal of cryptography in an enterprise estate is not a software component at all. It is a directive in a load balancer configuration, a host key algorithm list, a signing step in a pipeline, a key object in a vault, a mechanism enabled on a hardware module. None of that has a package name.

On tooling: the sensible path is to align with the SBOM ecosystem rather than compete with it. CycloneDX-style formats already model components, dependencies and provenance, and extending that shape to cryptographic assets is where the industry is heading. Our export is designed to sit alongside an existing SBOM pipeline, not to replace it.

#What a CBOM is actually good for

It is worth being blunt about the value, because CBOM is on its way to becoming a term used loosely. An inventory document is only useful when a specific person can do a specific thing with it that they could not do before.

• Migration planning. Sequencing depends on knowing which assets share a certificate authority, a library, a base image or an HSM partition. A machine-readable inventory makes that a query rather than a workshop. See Sequencing a migration.
• Regulatory evidence. Obligations under DORA, which applies from 17 January 2025, and federal timelines under NSA CNSA 2.0 both start from an inventory. A CBOM is the form of that inventory an assessor can process.
• Change detection. Two CBOMs from two runs diff cleanly on asset fingerprints, so a new quantum-vulnerable listener appearing in production is a detectable event rather than a discovery next quarter.
• Supplier assurance. Asking a supplier for a CBOM is a far more answerable request than asking whether they are post-quantum ready, and the answer can be checked.
• Internal ownership. Mapping assets to owning teams turns a central programme into distributed work with named accountability.

What a CBOM is not good for is proving posture. It records what is in use, not whether that is acceptable. The judgement layer is the scoring method, and the two should not be conflated in a document you hand to an auditor.

#Our export, and what is not settled

The inventory behind a CBOM export exists today and is what every AutoPQC report is built from. The exact serialisation we publish as a supported, versioned artefact is not finalised, and we would rather say that than publish a schema we intend to change.

The illustration that follows shows the fields our asset model already carries, so you can see what information will be available whatever the final envelope turns out to be. It is illustrative only.

{
  "run": {
    "estate": "example-estate",
    "collected": "2026-07-24",
    "surfacesCollected": ["edge", "pki", "source", "image", "keystore", "access"],
    "surfacesSkipped": [{ "surface": "build", "reason": "no pipeline credential in scope" }]
  },
  "assets": [
    {
      "fingerprint": "af-3f9c1d84",
      "surface": "edge",
      "location": { "host": "payments-gw.internal", "port": 443 },
      "primitive": { "family": "ECDH", "group": "P-256" },
      "role": "key-establishment",
      "owner": "payments-platform",
      "evidence": [
        {
          "detector": "edge.tls-handshake@3",
          "observed": "TLS 1.2, ECDHE-RSA, P-256, SHA-256",
          "confidence": "high"
        }
      ]
    },
    {
      "fingerprint": "af-71b2e055",
      "surface": "keystore",
      "location": { "vault": "prod-kv-01", "keyHandle": "signing/release" },
      "primitive": { "family": "RSA", "keySize": 2048 },
      "role": "signing",
      "owner": "unassigned",
      "evidence": [
        {
          "detector": "keystore.object-census@2",
          "observed": "type=RSA, size=2048, created=2019-04-11, rotation=none",
          "confidence": "high"
        }
      ]
    }
  ]
}

Note what is absent. There is no risk score, no tier and no recommendation in the document. Those come from the scoring method, are stamped with a method version, and are exported separately so that a CBOM remains a statement of fact.

#Fields we treat as mandatory

Whatever envelope the final format uses, we will not ship a CBOM that omits any of the following. Each exists because a reviewer who lacks it cannot check the document.

1. 01Asset fingerprint — so two runs can be compared rather than merely both read.
2. 02Location, at the most specific stable address available — so an engineer can go and look.
3. 03Primitive and parameters — family plus key size, curve or group, because a family alone does not determine exposure.
4. 04Role — key establishment, authentication, signing, encryption at rest, integrity or key wrapping.
5. 05Detector name and version — provenance for every claim.
6. 06Confidence — high, medium, low or unresolved, per the detector catalogue.
7. 07Run coverage — surfaces collected and surfaces skipped, with reasons, inside the document itself.

#Limits of the artefact

A CBOM inherits every boundary of the run that produced it. Coverage gaps, out-of-reach systems and confidence characterisations all travel into the document, which is the point of carrying them in the file rather than in a summary slide.

It is also a snapshot. An estate that deploys daily will have moved by the time the document is read, which is why the useful operating pattern is scheduled re-runs and a diff, not a one-off inventory filed for the auditor. The honest reading of any CBOM is: this is what was recorded, on these surfaces, on this date, by these detectors.