CycloneDX has quietly become one of the most capable SBOM specifications available, and the 1.5 release solidified that position. If you are running a software supply chain security program, this version introduced several features that are worth understanding deeply, even if your tooling has not caught up yet.
A Quick Refresher on CycloneDX
CycloneDX is an OWASP project that defines a standard for Software Bills of Materials. Unlike SPDX, which originated in the licensing and compliance world, CycloneDX was built with security use cases as a first-class concern. It supports multiple BOM types: software, hardware, operations, SaaS, and as of v1.5, machine learning models.
The specification uses JSON and XML serialization formats and is designed to be machine-readable first. This makes it well-suited for automation in CI/CD pipelines, policy enforcement, and vulnerability correlation.
What Changed in v1.5
1. Formulation
This is arguably the most significant addition. Formulation describes how a component was built -- the build environment, tools, workflows, and configuration that produced the software artifact. Think of it as capturing the provenance of your build process in a structured, standardized way.
Formulation supports describing:
- Workflows: The steps involved in building, testing, and packaging software
- Tasks: Individual units of work within a workflow (compile, test, sign, publish)
- Workspaces: The environment in which tasks execute
- Resource references: Links to source code, configuration files, and build scripts
This matters because understanding how software was built is critical for supply chain security. The SolarWinds attack succeeded precisely because the build process was compromised while the source code remained clean. Formulation gives you a structured way to describe and verify build processes.
If you are familiar with SLSA (Supply-chain Levels for Software Artifacts), formulation aligns closely with the provenance requirements at SLSA levels 2 and above. The difference is that CycloneDX embeds this information directly in the BOM alongside component and vulnerability data, giving you a single document that describes what is in the software and how it was made.
2. Machine Learning BOM (ML-BOM)
With ML models being deployed in production at an accelerating pace, the industry needed a way to inventory them just like we inventory software libraries. CycloneDX v1.5 introduces first-class support for machine learning model metadata.
An ML-BOM can describe:
- Model card information: The model's name, version, author, and description
- Datasets: Training, validation, and evaluation datasets used
- Model parameters: Architecture, quantization, input/output formats
- Performance metrics: Accuracy, precision, recall, F1 score, and custom metrics
This is not just academic. If your organization deploys ML models, you need to track what training data was used (for compliance and bias auditing), what version of the model is in production, and what its known limitations are. An ML-BOM gives you that inventory in the same format you already use for software components.
3. Expanded Evidence and Occurrences
Previous versions of CycloneDX supported basic evidence for component identity -- essentially, how was this component detected? Version 1.5 significantly expands this with the concept of occurrences.
An occurrence describes where a component was found in the analyzed artifact. This is crucial for addressing a common complaint about SBOMs: "How do I know this dependency is actually in my deployed artifact and not just a build-time transitive dependency?"
Evidence now supports:
- Identity evidence: How the component was identified (manifest analysis, binary analysis, hash matching)
- Occurrences: Specific file paths and locations where the component was found
- Callstack: For reachability analysis, showing the actual code paths that invoke a vulnerable component
This last point is particularly valuable. If a vulnerability exists in a function that your application never calls, the risk profile changes significantly. Callstack evidence in the BOM provides a structured way to convey that information.
4. Licensing Improvements
CycloneDX v1.5 added support for license acknowledgment types: "declared" and "concluded." This aligns with how SPDX handles license information and resolves a gap that was frequently cited by organizations doing license compliance work alongside security.
A declared license is what the component author states. A concluded license is what your analysis determines after examining the actual source code. These can differ, and distinguishing between them matters for legal compliance.
5. Tags
A simple but useful addition: components, services, and other BOM elements can now be tagged with arbitrary labels. This sounds minor, but it enables categorization schemes that are specific to your organization.
For example, you might tag components as "internet-facing," "handles-PII," or "business-critical." These tags can then drive policy decisions downstream without requiring changes to the specification itself.
Practical Implications for Your SBOM Program
If You Are Just Starting Out
Start generating CycloneDX v1.5 BOMs immediately. Even if you cannot populate every new field today, choosing the latest version means your tooling will be forward-compatible. Most major SBOM generators (Syft, Trivy, cdxgen) already support v1.5 output.
If You Have an Existing Program
Audit your current BOM generation to see what evidence fields you are populating. Many tools generate minimal BOMs with component names and versions but skip evidence, formulation, and licensing details. Work with your tooling vendors to increase the fidelity of your BOMs over time.
If You Are Consuming BOMs from Suppliers
Update your intake requirements. If you are asking suppliers for SBOMs, specify CycloneDX v1.5 as the minimum version and list the fields you expect to be populated. Component identity without evidence or provenance data is significantly less useful.
Build Pipeline Integration
Formulation data should be generated as part of your CI/CD pipeline, not after the fact. Capture the build environment, tool versions, and workflow steps at build time and embed them in the BOM. This is the only way to get accurate provenance information.
The Versioning Question
One question teams often ask is whether they should continue supporting CycloneDX v1.4 alongside v1.5. The answer depends on your ecosystem. If your consumers or suppliers are locked to v1.4 tooling, maintain backward compatibility. But push for v1.5 adoption wherever you can, because the new features address real gaps in supply chain visibility.
CycloneDX v1.6 has also been released with additional improvements, but v1.5 remains the most widely supported version with production-grade tooling across the ecosystem.
How Safeguard.sh Helps
Safeguard.sh supports CycloneDX v1.5 natively, including the expanded evidence and formulation fields. When you upload a BOM, Safeguard.sh parses the full specification -- not just component names and versions, but evidence, occurrences, and provenance metadata.
This means you get richer vulnerability correlation (because occurrence data tells us whether a vulnerable component is actually deployed), better audit trails (because formulation data captures build provenance), and more accurate risk scoring. If your suppliers provide CycloneDX v1.5 BOMs, Safeguard.sh validates them against the specification and flags missing fields, helping you enforce the quality standards your program requires.