5 Overview
This section contains a non-normative overview of CycloneDX.
CycloneDX is a modern standard for the software and system supply chain. Originating in the OWASP community in 2017, it has grown into a general-purpose Bill of Materials (BOM) standard capable of representing software, hardware, services, and other forms of inventory.
Backed by a formal governance model and global community support, CycloneDX has matured into an OWASP flagship project and, in December 2025, was formally adopted as an Ecma International Standard.
5.1 Purpose and benefits
At its core, CycloneDX enables software and system transparency. It provides detailed information about components such as versions, suppliers, and dependencies, allowing organizations to:
- Identify and manage risks across complex supply chains
- Facilitate compliance with regulatory and contractual requirements
- Build trust across the supply chain
This transparency supports a wide range of use cases.
CycloneDX continues to evolve to address emerging industry challenges. With each new release, it introduces features and improvements designed to stay ahead of the changing threat landscape and meet the needs of a broad spectrum of stakeholders, from developers and security teams to regulators and supply chain partners.
5.2 Design philosophy and guiding principles
The simplicity of design is at the forefront of the CycloneDX philosophy. The format is easily understandable by a wide range of technical and non-technical roles. CycloneDX is a full-stack BOM format with many advanced capabilities that are achieved without sacrificing the design philosophy. Some guiding principles influencing its design include:
- Be easy to adopt and easy to contribute to
- Identify risk to as many adopters as possible, as quickly as possible
- Avoid blockers that prevent the identification of risk
- Continuous improvement - innovate quickly and improve over time
- Encourage innovation and competition through extensions
- Produce immutable and backward-compatible releases
- Focus on high degrees of automation
- Provide a smooth path to specification compliance through prescriptive design
Defining Software Bill of Materials
The U.S. Cybersecurity & Infrastructure Security Agency (CISA) defines software bill of materials as "a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships." OWASP CycloneDX implements this definition and extends it in many ways.
The Role of SBOM in Software Transparency
Software transparency involves providing clear and accurate information about the components used in an application, including their name, version, supplier, and any dependencies required by the component. This information helps identify and manage the risks associated with the software whilst also enabling compliance with relevant regulations and standards. With the growing importance of software in our daily lives, transparency is critical to building trust in software and ensuring that it is safe, secure, and reliable.
SBOMs are the vehicle through which software transparency can be achieved. With SBOMs, parties throughout the software supply chain can leverage the information within to enable various use cases that would not otherwise be easily achievable. SBOMs play a vital role in promoting software transparency, allowing users to make informed decisions about the software they use.
Conformance and Alignment
The CycloneDX Standard exceeds the requirements outlined in the CISA Minimum Elements for an SBOM as well as the SBOM requirements defined by the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). In addition, CycloneDX supports and advances the secure development practices recommended in NIST’s Secure Software Development Framework (SSDF), and provides the structured transparency needed to help organizations meet obligations under the European Union Cyber Resilience Act (CRA).
A few high-level use cases for SBOM include:
- Product security, architectural, and licence risk
- Procurement and M&A
- Software component transparency
- Supply chain transparency
- Vendor risk management
xBOM Capabilities
CycloneDX provides advanced supply chain capabilities for cyber risk reduction. Among these capabilities are:
- Software Bill of Materials (SBOM)
- Software-as-a-Service Bill of Materials (SaaSBOM)
- Hardware Bill of Materials (HBOM)
- Machine Learning Bill of Materials (ML-BOM)
- Cryptography Bill of Materials (CBOM)
- Operations Bill of Materials (OBOM)
- Manufacturing Bill of Materials (MBOM)
- Bill of Vulnerabilities (BOV)
- Vulnerability Disclosure Report (VDR)
- Vulnerability Exploitability eXchange (VEX)
- CycloneDX Attestations (CDXA)
- Common Release Notes Format
Software Bill of Materials (SBOM)
SBOMs describe the inventory of software components and services and the dependency relationships between them. A complete and accurate inventory of all first-party and third-party components is essential for risk identification. SBOMs should ideally contain all direct and transitive components and the dependency relationships between them.
Software-as-a-Service BOM (SaaSBOM)
SaaSBOMs provide an inventory of services, endpoints, and data flows and classifications that power cloud-native applications. CycloneDX is capable of describing any type of service, including microservices, Service Orientated Architecture (SOA), Function as a Service (FaaS), and System of Systems.
SaaSBOMs complement Infrastructure-as-Code (IaC) by providing a logical representation of a complex system, complete with an inventory of all services, their reliance on other services, endpoint URLs, data classifications, and the directional flow of data between services. Optionally, SaaSBOMs may also include the software components that make up each service.
Hardware Bill of Materials (HBOM)
CycloneDX supports many types of components, including hardware devices, making it ideal for use with consumer electronics, IoT, ICS, and other types of embedded devices. CycloneDX fills an important role in between traditional eBOM and mBOM use cases for hardware devices.
Machine Learning Bill of Materials (ML-BOM)
ML-BOMs provide transparency for machine learning models and datasets, which provide visibility into possible security, privacy, safety, and ethical considerations. CycloneDX standardizes model cards in a way where the inventory of models and datasets can be used independently or combined with the inventory of software and hardware components or services defined in HBOMs, SBOMs, and SaaSBOMs.
Cryptography Bill of Materials (CBOM)
A Cryptography Bill of Materials (CBOM) describes cryptographic assets and their dependencies. Discovering, managing, and reporting on cryptographic assets is necessary as the first step on the migration journey to quantum-safe systems and applications. Cryptography is typically buried deep within components used to compose and build systems and applications. As part of an agile cryptographic approach, organizations should seek to understand what cryptographic assets they are using and facilitate the assessment of the risk posture to provide a starting point for mitigation.
Operations Bill of Materials (OBOM)
OBOMs provide a full-stack inventory of runtime environments, configurations, and additional dependencies. CycloneDX is a full-stack bill of materials standard supporting entire runtime environments consisting of hardware, firmware, containers, operating systems, applications, and libraries. Coupled with the ability to specify configuration makes CycloneDX ideal for Operations Bill of Materials.
Manufacturing Bill of Materials (MBOM)
CycloneDX can describe declared and observed formulations for reproducibility throughout the product lifecycle of components and services. This advanced capability provides transparency into how components were made, how a model was trained, or how a service was created or deployed. In addition, every component and service in a CycloneDX BOM can optionally specify formulation and do so in existing BOMs or in dedicated MBOMs. By externalizing formulation into dedicated MBOMs, SBOMs can link to MBOMs for their components and services, and access control can be managed independently. This allows organizations to maintain tighter control over what parties gain access to inventory information in a BOM and what parties have access to MBOM information which may have higher sensitivity and data classification.
Bill of Vulnerabilities (BOV)
CycloneDX BOMs may consist solely of vulnerabilities and thus can be used to share vulnerability data between systems and sources of vulnerability intelligence. Complex vulnerability data can be represented, including the vulnerability source, references, multiple severities, risk ratings, details and recommendations, and the affected software and hardware, along with their versions.
Vulnerability Disclosure Report (VDR)
VDRs communicate known and unknown vulnerabilities affecting components and services. Known vulnerabilities inherited from the use of third-party and open-source software can be communicated with CycloneDX. Previously unknown vulnerabilities affecting both components and services may also be disclosed using CycloneDX, making it ideal for Vulnerability Disclosure \Report (VDR) use cases. CycloneDX exceeds the data field requirements defined in ISO/IEC 29147:2018 for vulnerability disclosure information.
Vulnerability Exploitability eXchange (VEX)
VEX conveys the exploitability of vulnerable components in the context of the product in which they're used. VEX is a \subset of VDR. Oftentimes, products are not affected by a vulnerability simply by including an otherwise vulnerable \component. VEX allows software vendors and other parties to communicate the exploitability status of vulnerabilities, providing clarity on the vulnerabilities that pose a risk and the ones that do not.
CycloneDX Attestations (CDXA)
CycloneDX Attestations enable organizations to communicate security standards, claims, and evidence about security requirements, and attestations to the veracity and completeness of those claims. CycloneDX Attestations is a way to manage "compliance as code."
Common Release Notes Format
CycloneDX standardizes release notes into a common, machine-readable format. This capability unlocks new workflow potential for software publishers and consumers alike. This functionality works with or without the Bill of Materials capabilities of the specification.
5.3 CycloneDX object model
Within the root element, CycloneDX defines the following object types:
The object types are arranged in order and contain (but are not limited to) the following types of data:
BOM Identity
The bom element has properties for serialNumber and version. Together these two properties form the identity of a BOM. A BOM's identity can be expressed using a BOM-Link, a formally registered URN capable of referencing a BOM or any component, service, or vulnerability in a BOM. Refer to the chapter on Relationships for more information.
Serial Number
Every BOM generated should have a unique serial number, even if the contents of the BOM have not changed over time. If specified, the serial number shall conform to RFC 4122. The use of serial numbers is recommended.
Version
Whenever an existing BOM is modified, either manually or through automated processes, the version of the BOM should be incremented by 1. When a system is presented with multiple BOMs with identical serial numbers, the system should use the most recent version of the BOM. The default version is '1'.
The Anatomy of a CycloneDX BOM
The following are descriptions of the root-level elements of a CycloneDX BOM.
Metadata
BOM metadata includes the supplier, manufacturer, and target component for which the BOM describes. It also includes the tools used to create the BOM, and licence information for the BOM document itself.
Components
Components describe the complete inventory of first-party and third-party components. The specification can represent software, hardware devices, machine learning models, source code, and configurations, along with the manufacturer information, licence and copyright details, and complete pedigree and provenance for every component.
Services
Services represent external APIs that the software may call. They describe endpoint URIs, authentication requirements, and trust boundary traversals. The data flow between software and services can also be described, including the data classifications and the flow direction of each type.
Dependencies
CycloneDX provides the ability to describe components and their dependency on other components. The dependency graph is capable of representing both direct and transitive relationships. Components that depend on services can be represented in the dependency graph, and services that depend on other services can be represented as well.
Compositions
Compositions describe constituent parts (including components, services, and dependency relationships) and their completeness. The aggregate of each composition can be described as complete, incomplete, incomplete first-party only, incomplete third-party only, or unknown.
Vulnerabilities
Known vulnerabilities inherited from the use of third-party and open-source software and the exploitability of the vulnerabilities can be communicated with CycloneDX. Previously unknown vulnerabilities affecting both components and services may also be disclosed using CycloneDX, making it ideal for both vulnerability disclosure and VEX use cases.
Formulation
Formulation describes how something was manufactured or deployed. CycloneDX achieves this through the support of multiple formulas, workflows, tasks, and steps, which represent the declared formulation for reproduction along with the observed formula describing the actions which transpired in the manufacturing process.
Annotations
Annotations contain comments, notes, explanations, or similar textual content which provide additional context to the object(s) being annotated. They are often automatically added to a BOM via a tool or as a result of manual review by individuals or organizations. Annotations can be independently signed and verified using digital signatures.
Definitions
Standards, requirements, levels, and all supporting documentation are defined here. CycloneDX provides a general-purpose, machine-readable way to define virtually any type of standard. Security standards such as OWASP ASVS, MASVS, SCVS, and SAMM are available in CycloneDX format. Standards from other bodies are available as well. Additionally, organizations can create internal standards and represent them in CycloneDX.
Declarations
Declarations describe the conformance to standards. Each declaration may include attestations, claims, counter-claims, evidence, counter-evidence, along with conformance and confidence. Signatories can also be declared and supports both digital and analogue signatures. Declarations provide the basis for "compliance-as-code".
Citations
Citations provide structured attributions within a BOM, identifying which entity or process supplied specific pieces of information. Each citation associates data with the component, service, tool, organization, person, or process through JSON Pointers or path expressions, over time. When combined with CycloneDX Attestations and/or Formulation, citations provide even greater assurance by linking attributions to evidence of integrity and to the processes that generated or transformed the data. This integration enables consumers to not only see who supplied the information, but also verify its authenticity and understand the context in which it was created.
Extensions
Multiple extension points exist throughout the CycloneDX object model, allowing fast prototyping of new capabilities and support for specialized and future use cases. The CycloneDX project maintains extensions that are beneficial to the larger community. The project encourages community participation and the development of extensions that target specialized or industry-specific use cases.
Serialization Formats
CycloneDX can be represented in JSON, XML, and Protocol Buffers (protobuf) and has corresponding schemas for each.
| Format | Resource | URL |
|---|---|---|
| JSON | Documentation | https://cyclonedx.org/docs/latest/json/ |
| JSON | Schema | https://cyclonedx.org/schema/bom-1.7.schema.json |
| XML | Documentation | https://cyclonedx.org/docs/latest/xml/ |
| XML | Schema | https://cyclonedx.org/schema/bom-1.7.xsd |
| Protobuf | Schema | https://cyclonedx.org/schema/bom-1.7.proto |
CycloneDX relies exclusively on JSON Schema, XML Schema, and protobuf for validation. The entirety of the specification can be validated using officially supported CycloneDX tools or via hundreds of available validators that support JSON Schema, XML Schema, or protobuf.