All about CycloneDX 1.5
Jul 9, 2023
Interlynk
CycloneDX is one of the three SBOM specifications recommended by NTIA/CISA.
The CycloneDX team released their newest version - 1.5, on June 26th. This version packs features that cover new SBOM use cases and expands existing capabilities.
Let’s dig in.
xBOM Expansion

Source: CycloneDX capabilities
CycloneDX is known for its flexibility to support a variety of BOM types, such as SBOM, SaaSBOM, and HBOM. CycloneDX 1.5 expands the use cases in four directions :
ML-BOM: SBOM for applications using Machine Learning
MBOM: Classical BOM as CycloneDX alongside processes and testing
KBOM: SBOM for Kubernetes clusters
SBOM for Low-Code Applications
ML-BOM
This version supports building a Machine Learning Bill of Materials (ML-BOM) as a CycloneDX document. With version 1.5, CycloneDX can help document machine learning models and datasets as part of the SBOM components. ML-BOM documents can assist in documenting and sharing the model’s methods, constraints, and related concerns, such as ethical AI or data privacy.
In the specification, ML-BOM features are created by including machine-learning-model and data to the type of components node from CycloneDX 1.4. The spec also includes externalReferences the new type model-card. This reference describes the intended use of a machine learning model, potential limitations, biases, ethical considerations, training parameters, and other ML transparency data.
MBOM
This version can describe how a product is made, termed the Manufacturing Bill of Materials (MBOM). This is an improvement over classical BOM (list of manufacturing components) because MBOM, alongside components, includes all parts, including hardware, firmware, software, processes, and testing.
MBOM features are the inclusion of new types to components node:
platform
device-driverdata
MBOM also uses newly introduced formulation node to describe how a component or service was manufactured or deployed. This node supports the inclusion of details for formulas, tasks, steps, and any services. In addition, each component can specify its formulation as well, enabling recursive formulation through the entire build process.
Finally, externalReferences types are expanded to include new types for evidence, formulation, quality-metrics, and codified-infrastructure.
KBOM
Open-source security scanner Trivy by Aqua uses CycloneDX 1.5 to generate the Kubernetes Bill of Materials (KBOM). KBOM can be used to document the composition of a cluster, manifests of components, versions, and images.

Source: Introducing KBOM — Kubernetes Bill of Materials
KBOM uses CycloneDX 1.5 to break the cluster into logical entities “Control Plane,” “Nodes,” and “Addons,” — enabling an offline analysis of the cluster alongside its vulnerability and security monitoring.
SBOM for Low-Code Applications
The complexity of low-code applications is hidden behind low-code platforms. This version of CycloneDX allows a low-code platform to document the state of each application separately.
Features Expansion

Source: OWASP Authoritative Guide to SBOM: Lifecycle Phases
CycloneDX 1.5 improves the existing coverage of SBOM with specific improvements to documenting:
SDLC Lifecycle stage for SBOM creation
Commercial Licenses
BOM Maturity Model
SBOM Quality
Known Unknowns in Components
Proof of Concept for Vulnerability
Lifecycle Stage
CycloneDX defines seven lifecycle stages: Design, Pre-Build, Build, Post-Build, Operations, Discovery, and Decommission. In addition, the same field can be used to define a custom lifecycle phase along with the description of such a phase. The Authoritative Guide to SBOM calls lifecycle to be useful for Software Asset Management (SAM) and IT Asset Management (ITAM). Pre-defined lifecycle stages show CISA’s SBOM document types based on the point of creation.
CycloneDX 1.5 includes lifecycle as part of the metadata node that previously included timestamp, tools, supplier, licenses, and authors.
Commercial Licenses
This release also adds support for documenting commercial licenses in the SBOM. This, alongside open-source license support inherited from CycloneDX 1.4, provides a robust mechanism for documenting all licenses within a product. License management, including tracking license usage, renewals, and potential violations, powers SBOM to meet SAM and ITAM requirements.

Source: Commercial License Expression in CycloneDX 1.5
BOM Maturity Model
The OWASP Software Component Verification Standard (SCVS) evaluates an organization’s software supply chain maturity. The three levels of SCVS allow evaluation of Inventory, SBOM, Build Environment, Package Management, Component Analysis, & Pedigree, and Provenance of components.
The BOM Maturity Model derived from SCVS enables the evaluation of SBOM against preset policies. Such evaluation can provide feedback to SBOM generators such as SBOM tools or component vendors.
SBOM Quality

Source: Commercial License Expression in CycloneDX 1.5
The Authoritative Guide to SBOM describes all of the new CycloneDX 1.5 features. The same document establishes SBOM “quality” as a multidimensional construct for Breadth, Depth, Lifecycles, Techniques, and Confidence.
The fields lifecycle and evidence play a key role in specifying the quality of the SBOM. evidence provides the ability to document evidence collected through various forms of extraction or analysis.
Within the CycloneDX specification evidence is recorded on components > evidence node per component. The values can include confidence in the evidence, tools used, and callstack for the evidence.
Known Unknown for Components

Source: Authoritative Guide to SBOM
CycloneDX 1.5 improves recording the completeness of SBOM by introducing new fields to compositions > aggregate node for clarifying the completeness of — first and third-party, proprietary, and open-source components.
Proof of Concept for Vulnerability
Vulnerability disclosure and management also improved with CycloneDX 1.5. The specification permits the recording proofOfConcept node under Vulnerabilities that can capture — reproduction steps, environment, and supporting material for any known proof of concept.
The vulnerabilities node also supports recording rejected as the date and time (timestamp) when the vulnerability record was rejected (if applicable).
CycloneDX continues to progress towards improving coverage of the SBOM and improving how the data should be interpreted and used.
TABLE OF CONTENT
