Handling older CBOM files
The term "older" is ambiguous until the versions involved are separated. Three items each carry a version and change independently. A conformance claim must reference all three to be reproducible.
Three version axes
| Axis | Example | Changes when |
|---|---|---|
| Carrier format | CycloneDX specVersion 1.6 → 1.7 | the SBOM/CBOM standard is revised |
| Profile | interface-disclosure v0.2 → v0.3 | the requirements change |
| Content revision | a product's CBOM version over time | the product or a re-scan changes |
A newly generated CBOM (a new content revision) may still be serialized in CycloneDX 1.6 (an older carrier) and evaluated against profile v0.3 (newer rules). Conflating these axes is a common error.
Two of these axes are now recorded data rather than local convention. The 2026 minimum elements guidance adds SBOM Data Format Name and SBOM Data Format Version, which give the carrier axis, and SBOM Version, which gives the content-revision axis. Its Frequency element expects a new bill of materials for each build or release, so content revisions are produced as a matter of course rather than on request. A producer meeting that baseline supplies the two values a validator needs to place a document on both axes. See References.
Carrier version bands
The profile declares an acceptance range so that older CBOMs are handled explicitly. The rules file specifies "appliesTo": { "cyclonedx": { "min": "1.6", "tested": "1.7" } }, and the validator applies a four-band policy:
The validator reports the band in which the CBOM falls. All four bands can be observed by evaluating the example CBOM at 1.7 and at 1.8, 1.6 and 1.5 copies. Four bands need four inputs: 1.7 is the tested version, 1.8 is newer than tested, 1.6 falls in the legacy window, and 1.5 is below the minimum and is refused.
Supporting recommendations
- Normalize at the adapter. Prefer CycloneDX 1.7 Cryptography Registry identifiers where present; for 1.6 free-text names, apply a versioned name map before the rules are evaluated.
- Upgrade rather than reject. Convert a legacy but supported CBOM mechanically (raise the version, attach registry identifiers, record provenance) rather than rejecting it; the conversion re-encodes existing facts and adds none. This is consistent with the expectation in the minimum elements guidance that organizations accommodate updates to bill-of-materials data, including corrections.
- Pin the profile version in every conformance claim, and tighten rules behind dated grace windows, so that a warning is emitted before a result changes to a failure.
- Deprecate, rather than delete, vocabulary. If
interfaceTypevalues change, retain recognition of the former values (mapped to their replacements) for at least one profile major version. - Track freshness and supersedence so that an older content revision is not treated as incorrect without cause.