Overview
A Cryptography Bill of Materials (CBOM) profile defines the subset of attributes that a CBOM is required to contain for a stated objective. It establishes a minimum reporting requirement rather than exhaustive coverage. This documentation describes the profile methodology using a worked example: an nginx web server whose CBOM is expressed in CycloneDX 1.7 and evaluated against a small, product-independent profile.
Scope of this documentation
The example profile, the Interface Disclosure Baseline, requires a product to declare its cryptographic interfaces, including the interface used to configure the product, and to describe each one. It does not reference a specific product or interface instance, and therefore applies to any product that terminates TLS, SSH, or IPsec. nginx serves only as the example subject. A single CBOM may satisfy several profiles at once.
The order of the sections in the sidebar is a reading order: concrete material first, the vocabulary collected under Reference for when a term is unfamiliar. It is deliberately not the clause order of the numbered draft, where Scope, Terms and Conformance appear early because a normative document has to be self-contained. The two orders serve different readers and the working group maintains both.
Suggested reading paths
Sections are written so that each can be read on its own. Reading straight through the sidebar works; the two routes below are shortcuts for the positions from which the material is most often approached, and each assumes the Introduction has been read.
| If you are | Read in this order | Why this route |
|---|---|---|
| Producing CBOMs a vendor, or a build or release team |
Model → Profile → Maturity → Confidentiality → Formats → Versioning | The vocabulary, then what a profile obliges you to declare, which depth of disclosure to aim at first and how to climb, which of it you are willing to publish and to whom, where each attribute is written in a document, and what happens to files you have already published when a version changes. |
| Requiring and reading CBOMs an operator or buyer assessing a supplier, an auditor or regulator |
Use Cases → Challenges → Profile → Conformance → Maturity → Confidentiality → Vulnerabilities → Governance | What a profile can be written to require, why the data supplied today is hard to use, and what a passing verdict does and does not assert. Conformance matters most here, Maturity is what to write into a requirement so that a supplier can start and a date can be set for more, Confidentiality is why a conforming document can still be a redacted one and what to ask for instead, Vulnerabilities is what a CBOM gives you when an advisory lands and what a passing verdict must not be read as saying about safety, and Governance covers the signing, provenance and retention a claim depends on. |
| Writing or approving a profile working group members, sector bodies |
Model → Method → Profile → PQC Migration → Governance | The methodology's own subject matter. Method gives the procedure, PQC Migration works one profile through it end to end, and Governance covers what happens once a profile is published. |
Two sections sit outside these routes and are read when the question arises rather than in sequence: Data Exposure, a design note on the harvest-now-decrypt-later threat and the attributes that would measure it, and Related Work, on how this fits the consortium's other models.
Contents
Introduction
One product, one CBOM and one buyer's question: why the document cannot answer it, and what a profile does about it.
Demo
Four example documents evaluated against the profile in the browser, including the four disclosure outcomes and a subject with no management interface.
Use Cases
Contexts in which profiles apply: PQC readiness, procurement, incident response, compliance reporting, and continuous integration.
Challenges
Lessons from SBOM adoption and the limitations of current CBOM standards.
Inventory
How CBOMs feed a cryptographic inventory, and how a CBOM is extracted from one for an internal, external, or supply-chain consumer.
Lifecycle Data
The cryptographic data available at each development and deployment phase, and the differences between phases.
Model
Relationships, endpoints and assets — the vocabulary the methodology is written in, with worked examples.
Objects
Every noun the methodology uses, in one place: what writes each one, how each is identified, and what is deliberately not modelled here.
Profile
The product-level and per-interface rules, the two directions of use, and the basis for a conformance decision.
Conformance
What may be assessed, what a verdict means, who may claim it, how a claim is expressed, and what conformance does not assert.
Maturity
Publishing a family of profiles ordered by depth, so a producer can conform at a reachable entry profile and climb, and a consumer can tell which depth a supplier reached.
Confidentiality
Public and restricted variants of one document, why the difference is expressed by which rules are withholdable, and what a consumer can tell from the variant it holds.
Policy Evaluation
Why derived judgements such as post-quantum posture are computed by external versioned policy rather than stored in the document.
Vulnerabilities
How cryptographic weakness is communicated alongside a CBOM: the three statements and their authors, the two kinds of weakness, and what a conforming document does not assert.
Method
The procedure for defining a profile, in twelve steps across five stages, with the tests to apply at each and the ways it goes wrong.
Worked use cases
Use cases carried through to a finished profile, in a section of their own. PQC migration is the first, IoT device estates is drafted, and the other seven purposes are described under Use Cases above.
Formats
The mapping of a single profile onto CycloneDX and SPDX, and the modelling gap common to both.
Data Exposure
The harvest-now-decrypt-later threat, why the cryptography alone does not measure it, and the data attributes that would.
Versioning
Handling of CBOM files across three version axes, with a machine-checkable acceptance range.
Governance
The CBOM lifecycle, signing and provenance, the arrangements for relating a CBOM to an SBOM, change control, and long-term stewardship.
Terms
The vocabulary in one place: the model, profile and conformance terms, every attribute and its permitted values, and the terms deliberately not used.
Related Work
How CBOM profiles relate to the PQC Maturity Model and other consortium efforts, and where one depends on the other.
Files
The profile rules file, the example CBOMs and the validator, with the commands to reproduce every result shown here.