Inventory and CBOMs
A CBOM and a cryptographic inventory are related but not the same thing. This section sets out how they differ and how they work together, so the role of a CBOM within a wider inventory is clear.
How a CBOM and an inventory differ
A CBOM is a bill of materials for a single artifact: a structured, machine-readable description of the cryptography that a specific component contains or uses, produced at a defined point in time. It is analogous to a software bill of materials.
A cryptographic inventory is an organization-wide record of the cryptography in use across systems, aggregated from many sources and maintained continuously. It supports risk management, compliance, and migration planning across the estate.
| Property | CBOM | Cryptographic inventory |
|---|---|---|
| Scope | a single artifact or component | the whole estate |
| Unit | a document (for example, CycloneDX) | a maintained dataset or register |
| Producer | a build pipeline or a scan of one component | a central function that aggregates many sources |
| Temporal character | point-in-time, versioned revisions | continuously maintained, longitudinal |
| Correlation | describes one component's cryptography | correlates cryptography across components and over time |
| Primary purpose | disclosure and conformance for one component | risk analysis, compliance, and migration planning for the organization |
How they relate
CBOMs are a primary input to a cryptographic inventory. The inventory is built by normalizing and correlating CBOMs from across the estate, together with data from other sources such as network and configuration discovery. A CBOM describes one component at one point in time; the inventory spans many components and is maintained over time.
Correlating records from different sources
The normalization step in the diagram above is drawn as a single box and carries most of the difficulty. Records arriving from a vendor CBOM, a build-time scan and a runtime discovery tool describe overlapping sets of things, and the inventory has to decide which records describe the same thing. Where it decides wrongly, it either counts one asset twice or merges two distinct assets, and neither error is apparent from the result.
Why identity is hard, and how far it is solved for each class of asset, is set out in Challenges, which owns that taxonomy. This section covers what an inventory does about it.
Decide the join key per asset class, and record which was used. An inventory that merges records without recording the basis for the merge cannot be audited later, and cannot be corrected when a producer changes identifier scheme. Where two records were merged on a certificate fingerprint and a third on issuer and serial, that is a fact about the inventory worth keeping.
Correlation has to hold across time as well as across tools. Tracking migration progress means comparing this quarter's record against last quarter's, and an inventory that cannot determine whether two records describe the same interface will report changes that did not occur and omit changes that did. This is the constraint that bites hardest on interfaces, because interfaceId is deliberately unconstrained and carries no meaning outside its document. In practice an inventory has to construct its own stable key from attributes that do not change — the subject, the protocol, and the endpoint roles — and accept that a producer restructuring its interfaces will break it.
A profile converts part of the problem into a procurement requirement. A profile can require a particular identifier form for each asset class it covers, which is what baseline rule I9 does by requiring a pkg: Package URL for the implementing library. An organization that specifies the identifier forms its suppliers must use has moved those classes out of the correlation problem entirely. It does not help with the classes that have no scheme, which is where the residual work sits.
Extracting a CBOM from the inventory
The inventory is a source of CBOMs as well as a destination for them. A CBOM can be extracted from the inventory to serve a specific consumer. That consumer may be internal, such as a security or architecture team that needs a description of the cryptography in a given system, or external, such as a client, an auditor, or a regulator. A common external case is a supply-chain request, where a customer or partner asks the organization for a CBOM covering a product or service it supplies.
An extracted CBOM is a scoped snapshot of the inventory. It is generated for a defined subject, such as a product, a service, or a bounded part of the estate. It is filtered to the content the consumer needs, redacted where confidentiality requires it, marked with its provenance (the inventory revision and the time it was drawn from), and signed where appropriate. See Governance.
A single profile applies in both directions. On input, it validates the CBOMs supplied to the inventory. On output, it validates a CBOM extracted from the inventory before that CBOM is released. A consumer making a supply-chain request can state which profile the returned CBOM must satisfy, and the producer checks the output against that profile before sending it. One set of rules therefore governs both the assembly of the inventory and the disclosures drawn from it.
The role of profiles
For CBOMs produced by different tools and vendors to be aggregated into a coherent inventory, they must be comparable. A profile defines the attributes each CBOM is required to contain, and, together with normalization at the adapter, ensures that values are expressed consistently. This comparability is a precondition for reliable aggregation. Without it, an inventory assembled from heterogeneous CBOMs cannot be relied upon. The same profile also applies to CBOMs extracted from the inventory, as noted above. See Challenges and Formats.
Distributed and central inventories
An inventory does not have to be a single database. In practice organizations tend to land somewhere between two arrangements, and the choice affects how profiles and normalization are applied.
A central inventory holds the collected data in one place. Data is gathered from across the estate, normalized on the way in, and queried centrally. Queries that span the estate are straightforward, and normalization happens once. The cost is that the central store must be kept current, and it can become a bottleneck for teams that own the underlying systems.
A distributed inventory leaves the data with the business units, subsidiaries, or regions that own it. Each maintains its own inventory, and estate-wide questions are answered by querying across them or by collecting summaries. This suits organizations where ownership is already devolved, or where data residency or confidentiality rules prevent detail from being pooled. The difficulty is that each participant may normalize differently, so an estate-wide answer is only as good as the agreement between them.
A common middle position is a federated arrangement: detail stays local, while an agreed subset is published upward for estate-wide reporting. This is where a profile earns its place. If every participant validates against the same profile, the published subsets are comparable even though the underlying inventories are separate and independently run. The profile defines the common denominator, and normalization is applied by each participant rather than once at the centre. Mergers, acquisitions, and outsourced operations tend to push organizations toward this arrangement whether or not it was planned.
End-to-end posture across a deployment
A recurring question is how CBOMs are linked to show the posture of a whole transaction path rather than of one product. No CBOM can show it, and assembling it is a function of the inventory.
A CBOM describes one subject's boundary. It does not record what sits on the other side of any of its interfaces, and it cannot do so: the same product is deployed into a different topology at every site, and a document that named its peers would be describing one deployment. That is the same instance-independence constraint that keeps profiles applicable to any product. A product CBOM that carried topology would in effect describe a single deployment.
What linking requires
Three things are needed, and the methodology currently defines none of them.
- Stable identity for the things being linked. A link is expressed between identified endpoints, and the interface identifier carries no meaning outside its own document. This is the correlation problem described above, and it is the first obstacle.
- A topology record. Something has to state that this product's interface connects to that product's interface. Only the operator knows that, and it changes when the deployment changes rather than when any product changes.
- A rule for composing posture along a path. The posture of the whole path has to be derived from the hops and their cryptography.
Composition is not simply the weakest hop
For protection in transit, the weakest hop governs: a path is only as protected as its least protected segment, and the diagram above shows a path where two strong hops are made irrelevant by one classical hop in the middle. The Model section works through why, and also why the rule does not generalize. Relationships overlap a path instead of partitioning it. A signature applied by the originator and verified by the service spans every hop at once, so its algorithm is not affected by any individual segment, and a path that is adequately protected in transit may still carry a signature that a quantum computer will forge. Posture is therefore composed separately for each relationship, and relationships differ in their extent.
Where this leaves the methodology
End-to-end posture is an inventory function. CBOMs supply the facts about each boundary, the inventory supplies the topology, and the composition is computed and dated in the same way as any other derived judgement described in Policy Evaluation. A service or deployment CBOM extracted from the inventory can legitimately carry linkage, because it describes instances, and the distinction between a product CBOM and a deployment CBOM in Lifecycle Data makes that possible without breaking product independence.
Context data that is not itself cryptographic
A cryptographic inventory that records only cryptography is difficult to act on. Knowing that a service negotiates X25519 says nothing about whether that matters. Deciding whether it matters, and how urgently, depends on data that is not cryptographic at all and usually already exists elsewhere in the organization.
| Context | Typical source | What it supports |
|---|---|---|
| Business criticality and service ownership | CMDB, service catalogue | Prioritizing which systems to migrate first, and identifying who is accountable for doing it. |
| Data classification and retention period | Data governance records | Assessing harvest-now-decrypt-later exposure. Data that must stay confidential for decades is more urgent than data that expires next quarter. |
| Regulatory scope and jurisdiction | Compliance register | Determining which deadlines and cryptographic requirements apply to a given system. |
| Deployment topology and network exposure | Network and infrastructure records | Distinguishing an internet-facing interface from one confined to a private segment. |
| Software and hardware composition | SBOM, HBOM, asset register | Establishing whether a change is a library update, a configuration change, or a hardware replacement. An SBOM meeting the 2026 minimum elements also carries the component hash algorithm, which is itself cryptographic data of interest to the inventory. |
| Lifecycle and support status | Asset management, vendor roadmaps | Identifying systems that will never receive a quantum-safe update and must be replaced. |
| Third-party and contractual relationships | Procurement records | Establishing which suppliers to approach, and what they are obliged to provide. |
Two consequences follow. First, the inventory needs stable identifiers so that a cryptographic record can be joined to the corresponding entries in these other systems. Correlation is usually more valuable than duplication: the inventory should reference the CMDB entry rather than copy its contents, which would then drift. Second, this context belongs outside the CBOM. A CBOM describes the cryptography of its subject; criticality and data classification are properties of the business, and they change on their own schedule. Keeping them separate is the same reasoning applied to derived evaluations in the Policy Evaluation section.
Multiple data sources and lifecycle stage
A cryptographic inventory typically combines CBOM data, which is frequently implemented or configured, with runtime discovery, which is observed. The lifecycleStage attribute allows the inventory to distinguish declared capability from observed use, rather than conflating the two. See Lifecycle Data.
Relationship to SBOM and HBOM inventories
A cryptographic inventory is generally maintained alongside software and, where relevant, hardware inventories. CBOMs are consumed together with SBOMs, and in some cases Hardware Bills of Materials, so that cryptography can be related to the components and hardware that implement it. This relationship determines, for example, whether a change requires a software update or a hardware replacement.
Foundational considerations for CBOM exchange
Using the inventory as both a source and a destination raises several points that a fuller treatment of this topic should cover:
- Subject and scope. An extracted CBOM should state its subject precisely (for example, a product, a service, or a defined portion of the estate) and the criteria used to select its content.
- Provenance and point-in-time. Because the inventory changes continuously, an extracted CBOM is a snapshot; it should record the inventory revision and the time from which it was produced.
- Authenticity. An output CBOM issued to an external party should be signed, so that the recipient can verify its origin and integrity. See Governance.
- Redaction and confidentiality. External disclosure may require redaction. The profile sets the lower bound of what must be disclosed; policy governs what is withheld. Redaction should be recorded rather than performed silently: an attribute removed on release is marked as withheld, so the recipient can see that the information exists and was not disclosed, instead of reading the gap as a limitation of the producer's tooling. See Challenges, and Confidentiality for what the public and restricted extracts of one subject owe each other.
- Format and version negotiation. A consumer may require a particular carrier format and version; the mapping and the profile's accepted version range determine what can be produced and validated. See Formats and Versioning.
- Derived evaluations excluded. Post-quantum posture and cryptographic maturity are not embedded in the extracted CBOM; the recipient derives them from the disclosed facts by policy. See Policy Evaluation.
- Identity and re-request. Stable identifiers allow the recipient to correlate the CBOM with the corresponding SBOM and HBOM, and to request an updated CBOM when the subject changes. The minimum elements guidance makes the same point for SBOMs through its Component Identifiers element, which expects machine-processable unique identifiers to support automated analysis.
- Request and response. A supply-chain request should state the profile and scope required; the response is validated against that profile and retained for audit.
- Trust asymmetry. Inputs to the inventory may come from lower-trust sources and require verification and normalization; outputs produced by the organization carry its own attestation.