CycloneDX 1.7 shipped in March 2026, and it is a quieter release than 1.6 in a good way. Where 1.6 introduced headline features like ML-BOM and expanded crypto metadata, 1.7 is the version that cleans up the rough edges, aligns with recent regulatory guidance, and makes the format genuinely pleasant to work with for teams that have been living inside it for a couple of years. The changes are incremental, but every one of them addresses a pain point our customers have hit in production.
This post walks through the features that matter for working SBOM pipelines. We cover the ML-BOM expansion, the attestation refinements, the VEX tightening, and the ergonomic improvements that make the format more usable for consumers. We also flag a handful of areas where the spec still leaves implementation choices on the table, because those choices are where interoperability breaks down if nobody pays attention.
What expanded in ML-BOM?
ML-BOM expanded to cover model cards, training data lineage, and inference-time dependencies with much more depth. 1.6 introduced the ML-BOM concept and let you describe a model as a component. 1.7 adds structured fields for training dataset provenance, evaluation metrics, and the specific framework versions used during training and inference. There is a new modelCard object that mirrors the community model card format, which is especially helpful for teams that need to satisfy the EU AI Act's technical documentation requirements.
The practical effect is that an ML-BOM in 1.7 can stand in for a full transparency artifact rather than being a partial list of model components. We have already seen regulated customers swap handwritten model cards for generated 1.7 ML-BOMs, which reduces the drift between the documentation and the actual deployed model. The generation tooling is still catching up; expect another six months before the popular ML frameworks emit 1.7 ML-BOMs natively.
How did attestations change?
Attestations got a tighter specification and a cleaner serialization. CycloneDX has supported an attestation predicate since 1.5, but the structure was loose enough that two conformant tools could produce meaningfully different representations of the same attestation. 1.7 pins down the attestation object, aligns it with the in-toto and SLSA predicate shapes, and adds explicit support for nested attestations so a single SBOM can carry build, source, and VEX attestations in a consistent structure.
The other attestation change is a new evidence object at the component level. Previously, evidence for how a component was identified, such as a file hash, a manifest entry, or a binary analysis match, was represented inconsistently across tools. 1.7 standardises the structure, including confidence scores and identification technique names. This is the single biggest interoperability improvement in the release; consumers that previously had to special-case each tool's evidence format now have a canonical shape to parse.
What tightened in VEX?
VEX tightened around status justifications and affected range semantics. CycloneDX's inline VEX has been popular since 1.5 because it lets a single document carry both component inventory and exploitability information. The downside was that the justification vocabulary was looser than the OASIS CSAF VEX equivalent, which caused interoperability headaches with VEX consumers outside the CycloneDX ecosystem.
1.7 aligns the justification vocabulary with CSAF VEX 2.0 and adds new fields for tracking mitigation status over time. It also formalises the way VEX statements reference component versions, which prevents the common mistake of asserting "not affected" for a version range that does not actually contain the fix. The alignment means a CycloneDX VEX can now be translated losslessly to CSAF VEX, which matters for enterprises that exchange VEX with suppliers on different stacks.
What ergonomic improvements landed?
The ergonomic improvements are the ones end-users will feel most. JSON schema validation is stricter and clearer; error messages from the reference validator now tell you which field failed and why, rather than returning generic schema violations. The bom-ref reference resolution is better specified, so cross-document references work predictably when an SBOM is split into multiple files. And the canonicalisation rules for hashing and signing are explicit, which eliminates a class of "why does the signature not verify on this perfectly valid document" issues.
The spec also added a set of recommended profiles: minimum viable SBOM, NTIA-conformant, EU CRA-conformant, and FedRAMP-conformant. These profiles are not mandatory, but they give tooling and auditors a shared vocabulary for "which subset of the full CycloneDX feature set is expected in this context." We expect regulators to start referencing these profiles by name over the next year, and teams should plan to tag their outputs accordingly.
How should teams migrate?
Teams should migrate in phases. First, update SBOM consumers to tolerate 1.7 input while still accepting 1.6, which most CycloneDX libraries now do with a single config change. Second, update SBOM producers to emit 1.7 for net-new pipelines, validating against the new schema and the relevant profile. Third, backfill ML-BOM and attestation data for existing artifacts that need it, prioritising anything covered by regulatory scope.
Do not try to retrofit every historical SBOM to 1.7. The format supports consumers holding older documents indefinitely, and the cost of a mass re-generation usually exceeds the value. The exception is regulated components with long retention requirements, where a consistent format simplifies audit.
Where are the remaining ambiguities?
The remaining ambiguities cluster around multi-tenant environments, signed external references, and the boundary between SBOM and VEX. Multi-tenant environments sometimes produce SBOMs that describe infrastructure shared across customers, and the spec does not give crisp guidance on how to scope ownership. Signed external references, such as linking a component to a signed artifact in an OCI registry, are supported but the verification flow is not standardised. And teams continue to disagree about whether VEX belongs inline with the SBOM or in a separate artifact; 1.7 permits both but does not recommend.
How Safeguard Helps
Safeguard produces and consumes CycloneDX 1.7 natively, including full ML-BOM support with model card generation, attestation verification, and profile-based conformance checks against NTIA, EU CRA, and FedRAMP baselines. Reachability analysis runs against the 1.7 evidence object so you can distinguish CVEs with real exploitability from noise in your inventory. TPRM ingests VEX statements from your suppliers, aligns them with internal assessments, and tracks exploitability over time. Griffin AI reviews SBOM drift and flags silent component substitutions, and policy gates in CI block builds whose 1.7 documents fail your profile bar. You get the migration benefits without the migration work.