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.
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
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.
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 for runtime environment,
- device-driver for device-specific software control and
- data for recording any collection of discrete information.
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.
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.
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.
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.
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
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 themetadata node that previously included timestamp, tools, supplier, licenses, and authors.
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.
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.
The Authoritative Guide to SBOM describes all of the new CycleoneDX 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.
CycloneDX 1.5 improves recording the completeness of SBOM by introducing new fields tocompositions > aggregate node for clarifying the completeness of — first and third-party, proprietary, and open-source components.
Vulnerability disclosure and management also improved with CycloneDX 15. 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.
