Governance

Governance concerns the processes and controls that apply to CBOMs and profiles over their lifetime: how they are produced, authenticated, distributed, evolved, and retired. This section describes the areas of governance and their relationship to the rest of the methodology.

Revision states

A CBOM revision passes through four states, and governance controls each transition. The word lifecycle is reserved in this methodology for the capture phase of a reported fact, which is a different axis and is described under Lifecycle Data. A revision has states. A fact has a capture phase. They get run together because the same word was doing both jobs on this page until now.

Validation is not a state

A document does not change when somebody validates it. Validation happens to a published revision, repeatedly, by parties who never coordinate, and each occurrence leaves a conformance claim instead of moving the document anywhere. The four states belong to the producer and the curator. The claims belong to whoever made them.

That asymmetry is what governance has to account for: a revision is produced once and consumed for as long as anyone keeps a copy. Two consumers validating the same document against the same profile a year apart can reach different verdicts, because the profile was revised in between. A claim is bound to a document digest and pins a profile version for that reason.

A profile authority can change a verdict without anyone touching the document

Tightening a published profile alters whether existing revisions conform to it. No producer acted, no document changed, and the answer moved anyway. That power rests with the profile authority alone. Nothing else in the model can do it, which is why it is set out here rather than left implied.

It has two consequences. A profile authority revising a published profile should state what becomes of documents that conformed to the previous version, which is the grace-window question recorded as Q15. And the archive obligation below is what keeps the earlier verdict checkable: without the superseded profile text, the old claim cannot be reproduced and the change cannot be shown to have been a tightening rather than a rewrite.

Where the variants fork

A family with a public and a restricted variant forks at Create, not at Publish. The markers that make a document public are in the document itself, so a producer creates two, signs two, and publishes two to different audiences. They are superseded together: a restricted revision issued without its public counterpart leaves the public record describing a version that no longer exists.

How a producer manufactures the two is outside this methodology, and in practice both are extracts taken from one inventory at two redaction settings. What governance covers is the pair that arrives and the relationship between them. See Confidentiality.

Roles

Three of the four roles can move a revision between states. The fourth cannot, and has the larger power.

Integrity and authenticity (signing)

Signing is now an expected practice. The 2026 minimum elements guidance lists SBOM Author Signature among its minimum elements, defined as a digital signature attributable to the SBOM author, alongside SBOM Author, SBOM Tool Name and SBOM Tool Version. A bill of materials that cannot be attributed and verified no longer meets the stated baseline. See References.

A CBOM should be signed so that a consumer can verify its origin and detect subsequent modification. Two distinct objects may be signed:

• The CBOM document, by a detached digital signature over the serialized file, so that any alteration is detectable.
• The process that produced it, as a build attestation (for example, in the in-toto or SLSA model), so that the provenance of the CBOM is itself verifiable.

Signing depends on key management: the protection and rotation of signing keys, and a means for consumers to establish trust in the signing identity. Because the subject matter is cryptography, the signature algorithms are themselves in scope. A CBOM signed with a classical algorithm has an assurance horizon bounded by the strength of that algorithm, and the choice of signing algorithm should be governed on the same basis as the cryptography the CBOM describes. The minimum elements guidance takes the same view, referring authors to the ENISA agreed cryptographic mechanisms for the signature itself.

Provenance

A CBOM should record how it was produced: the generating tool and its version, the inputs, the lifecycle stage at which it was captured, and any mechanical upgrade applied to it (see Versioning). Provenance supports both trust and reproducibility, and is a precondition for a meaningful conformance claim. The tool name and version are now named minimum elements, so a producer meeting the SBOM baseline already carries most of what a CBOM consumer needs to judge how the data was obtained.

Provenance also has to say what is not there. Where an attribute is unavailable, the record should state whether the producer lacks the information or is withholding it, rather than leaving the field empty. See the discussion in Challenges.

Relating a CBOM to an SBOM

Cryptography does not exist apart from the software and hardware that implement it, so a CBOM is of limited use without some way to reach the component context. There is more than one way to arrange that, and the choice is a governance decision. It determines what is signed, who is accountable for which document, how often each is regenerated, and what a consumer has to fetch before it can act.

Four arrangements are in use. The first two produce a single document; the second two produce a pair with a reference between them.

A · Unified document

One bill of materials contains both the software components and the cryptographic assets, with dependencies expressed between them. CycloneDX supports this directly, since cryptographic assets are components like any other. The worked example on this site is of this kind: the OpenSSH and OpenSSL library components sit in the same document as the interfaces and algorithms that use them.

The advantage is that there is nothing to resolve and nothing to keep in step. A single signature covers the whole claim, one author is accountable, and a consumer holding the document has everything it needs. The disadvantage appears when the two kinds of data have different lifetimes or different owners. A vendor's software inventory changes on release; a deployment's cryptographic configuration can change without any software changing at all. Binding them into one artifact forces the slower-moving part to be republished whenever the faster-moving part does, and it means a consumer entitled to the software inventory necessarily receives the cryptographic detail as well.

B · Standalone CBOM

The CBOM is a single document that describes cryptography without reference to any software inventory. This is the appropriate arrangement when the subject is not a software artifact, for instance an operator describing the cryptography observed on a service it did not build, or a survey of an estate assembled from network discovery.

It is simple to produce and to distribute, and it avoids publishing software composition that the producer may not wish to disclose. It cannot answer the question that usually follows. If an algorithm needs replacing, the next question is which library implements it and whether that library can be updated. A standalone CBOM does not carry that information. Recording implementationPurl mitigates this by naming the implementing package even in the absence of a linked SBOM, which is why the profile asks for it.

C · CBOM referencing an external SBOM

The CBOM is the entry point and carries a reference to the SBOM for the same subject. A consumer starts from the cryptography and resolves outward to component detail when it needs it.

This suits consumers whose question is cryptographic: migration planners, and anyone assessing an interface rather than a release. The two documents keep independent lifecycles, so a configuration change can produce a new CBOM revision without reissuing the SBOM. The cost is referential integrity. A reference that names a document without pinning its revision will eventually point at something that has moved on, and a consumer that cannot resolve the reference is left with an incomplete picture and no indication that anything is missing.

D · SBOM referencing an external CBOM

The SBOM is the entry point and links to the CBOM as an external artifact. This is the arrangement the site describes for SPDX, because SPDX 3.0.1 has no cryptographic object model, so the practical option today is an SPDX SBOM alongside a CycloneDX CBOM.

Its strengths are distributional. Existing supply-chain processes already request, store and verify SBOMs, so a CBOM reached from an SBOM inherits those processes rather than requiring its own. Access can also be separated, which matters when an organization is willing to publish software composition more widely than cryptographic configuration. The weakness is that cryptography becomes a secondary artifact. A consumer that stops at the SBOM, or whose tooling ignores unfamiliar external references, never sees the CBOM at all, and there is no signal in the SBOM that anything is missing.

Comparison

Requirements that apply whichever is chosen

Where two documents are used, the reference between them has to be governed or it decays.

• Pin the revision. A reference should identify a specific revision of the target, not merely the target. CycloneDX provides a link form that identifies a BOM by serial number and version, which is the mechanism to prefer over a bare URL. Confirm the exact syntax against the current schema before relying on it.
• Give the pair a shared subject identifier. Both documents should name the same subject in the same way, so that a consumer holding one can find the other without following a link that may have rotted.
• State whether resolution is required for conformance. A profile should say whether an unresolvable reference is a failure or a warning. Silence here means two consumers will reach different verdicts on the same document.
• Sign both, and record the relationship. Two signatures do not by themselves attest that the two documents belong together. The reference should be inside the signed content of at least one of them.
• Keep retention aligned. A retained CBOM whose SBOM has been deleted is an audit record that can no longer be interpreted.

Evolution and change control

Profiles, the controlled vocabulary, and the methodology evolve over time. Changes are managed through explicit versioning (see Versioning), recorded decisions, and, within the working group, lazy consensus. Requirements are tightened behind dated grace windows, and vocabulary values are deprecated rather than removed, so that changes are predictable and auditable.

The working group's own record is kept in the repository. Decisions taken while drafting are written up in decisions/, one file per decision, stating the options considered and what reversing the decision would involve; a decision is superseded rather than deleted. Unresolved items are collected in the open questions register and mapped to the methodology aspect that tracks each one. A profile applies the same discipline to itself: the example baseline carries a changelog classifying each change as tightening, relaxing, or editorial, so that a producer can tell from the record whether a new version obliges further work.

Stewardship of profiles and mappings

Change control describes what happens when a profile is revised. Stewardship describes what happens over the years in which it is in use, and it is a separate question because a profile outlives the circumstances that produced it. A conformance claim made against a profile can be examined long after the group that wrote it has disbanded, and the claim is only meaningful if the profile it cites is still obtainable in the form it had at the time.

Profiles and mappings need different treatment. A profile changes when its author decides to change it. A mapping changes because a carrier format changed, on a schedule nobody in this working group controls. Mapping maintenance is therefore a standing obligation, and profile maintenance an occasional decision.

Areas to be assigned

The archive obligation

A conformance claim cites a profile version so that the result can be reproduced. An auditor examining a claim years later needs the text of that version as it stood when the claim was made, because a later version may require different things. If published versions are not retained and served, every claim becomes unverifiable as soon as the profile is revised, and the conformance model depends on that reproducibility.

This places an obligation on whoever publishes a profile: retain every published version indefinitely, addressable by its version identifier, and do not alter a published version in place. A correction is issued as a new version. The requirement matches the treatment of superseded CBOM revisions described below, and for the same reason.

Mappings track something the group does not control

A mapping states where each attribute sits in a concrete format. When CycloneDX or SPDX publishes a release, the mapping may become incomplete, or a limitation the documentation records may cease to be true. Neither event is triggered by anything the working group does, so neither will be noticed unless somebody is watching. Assigning that responsibility, and deciding how a superseded limitation is recorded, prevents the documentation from stating things about the formats that are no longer accurate.

Related open questions

Several questions already recorded in the open questions register belong to stewardship and are best settled together rather than one at a time: who may publish under a consortium namespace and who maintains the register; whether a published profile is signed and by whom; who tracks the carrier formats; whether raising the tested carrier version obliges a profile version increment; and how long a producer has when a profile is tightened.

Distribution, retention, and immutability

Published CBOM revisions should be immutable: a correction or update is issued as a new revision rather than an in-place change, and superseding revisions replace, but do not delete, their predecessors. The registry governs access control and retention. Retention of superseded revisions provides the audit trail on which progress tracking and incident investigation depend.

Immutability does not remove the obligation to correct. The minimum elements guidance expects organizations to accommodate updates to bill-of-materials data, including corrections, and expects authors to correct errors promptly. The two work together: the erroneous revision is retained for audit and a corrected revision supersedes it.

Conformance-claim governance

A conformance claim references the profile version, the carrier format version, and the CBOM content revision (see Versioning). Claims are recorded so that a stated result can be reproduced and audited. A claim that omits any of these three references is not reproducible. The form of a claim, the identification of the party making it, and the distinction between a self-declared and an attested claim are specified in Conformance.

Confidentiality and disclosure

Governance also addresses the boundary between disclosure and the protection of intellectual property. A profile establishes the lower bound of what must be disclosed; governance addresses the treatment of information beyond that bound, including any redaction policy and the conditions under which more detailed CBOMs are shared. Confidentiality sets out how a public and a restricted variant of one document relate to each other and to the profiles they clear, and why the aggregation and differencing risks are distribution questions that land here rather than in a profile. See also the discussion of depth of disclosure in Challenges.