CycloneDX is a lightweight Software Bill of Materials (SBOM) standard, originally created by the OWASP Foundation, designed to describe the components, dependencies, licenses, and security metadata of software so that organizations can assess and manage supply chain risk. If you've been asking "what is CycloneDX," the short answer is that it's a machine-readable manifest format — expressed in JSON, XML, or Protocol Buffers — that captures everything a piece of software is built from, down to individual libraries, container layers, and even hardware and machine-learning model components. Unlike a simple dependency lockfile, CycloneDX is purpose-built for security use cases: it supports vulnerability disclosure, pedigree and provenance tracking, cryptographic bill of materials, and license compliance in a single, extensible schema. Since its introduction in 2017, CycloneDX has become one of the two dominant SBOM formats worldwide, alongside SPDX, and is widely referenced in U.S. federal software supply chain guidance.
What Is CycloneDX?
CycloneDX is an open-source, OWASP-governed specification for generating a full inventory of a software application's components and their relationships. It was created specifically to close a gap that older formats left open: most existing manifest and package-lock formats could tell you what was installed, but not how secure it was, where it came from, or whether a known vulnerability actually affected it. A CycloneDX document lists every component — libraries, frameworks, services, containers, operating system packages, and even physical devices — along with metadata like package URLs (PURLs), cryptographic hashes, license identifiers, and supplier information. For example, a CycloneDX SBOM generated for a Java Spring Boot application would enumerate every JAR dependency pulled in via Maven, including transitive dependencies four or five levels deep, each tagged with its exact version and a hash that can be used to verify it hasn't been tampered with post-build.
How Does the CycloneDX SBOM Format Work?
The CycloneDX SBOM format works by structuring software metadata into a hierarchical document made up of components, services, dependencies, and vulnerabilities, all tied together by unique identifiers called BOM references. At the top level, a CycloneDX document has a metadata block describing the root application or product being documented — its name, version, and the tool that generated the SBOM. Below that sits a components array, where each entry represents a discrete piece of software: a library, framework, or file. Each component can carry a purl (Package URL), a cpe (Common Platform Enumeration identifier), license data, and hashes. A separate dependencies graph then maps which components rely on which others, letting tools reconstruct the full dependency tree rather than just a flat list.
Consider a real-world example: a fintech company shipping a Node.js payment microservice generates a CycloneDX SBOM during its CI build. The resulting JSON document lists the express web framework, its transitive dependency on body-parser, and a vulnerable version of a JSON-parsing library buried three layers deep. When a new CVE is published against that parsing library, the security team can query every CycloneDX SBOM in their inventory for that specific PURL and immediately identify every affected service — without re-scanning source code — because the SBOM already captured the exact version and location of the dependency.
How Is CycloneDX Different From SPDX?
CycloneDX differs from SPDX primarily in origin and emphasis: CycloneDX was built by the security community for security and risk use cases, while SPDX (Software Package Data Exchange) originated in the legal and licensing community under the Linux Foundation and has historically emphasized license compliance and provenance. In practice, the CycloneDX vs SPDX comparison comes down to depth versus breadth of standardization. CycloneDX has native, first-class support for vulnerability data, exploitability statements, and cryptographic bill of materials (CBOM) — features that make it easier to feed directly into vulnerability management pipelines. SPDX, now an ISO/IEC 5962:2021 international standard, has broader adoption in legal and government contexts and offers more granular license expression through the SPDX License List.
Both formats can represent the same underlying facts about a software package, and many organizations end up producing both because different downstream consumers request different formats — a customer's legal team might want SPDX for license auditing, while the same customer's security team wants CycloneDX because it plugs directly into their vulnerability scanner. Tools like Syft, Trivy, and CycloneDX's own official generators (cdxgen, CycloneDX Maven/Gradle plugins) can typically output both formats from a single scan, so choosing one doesn't necessarily mean abandoning the other.
What Is a CycloneDX VEX Document?
A CycloneDX VEX document is a Vulnerability Exploitability eXchange record that states whether a specific known vulnerability actually affects a specific product, and if so, what its exploitability status is. VEX was added to address a real operational problem: a component appearing in an SBOM might contain a vulnerable function that is never actually called or reachable in the way the application uses it, meaning the vulnerability poses no real risk despite showing up in every automated scan. CycloneDX VEX documents let a software vendor formally declare a status — affected, not_affected, fixed, or under_investigation — along with a justification, such as "vulnerable code is not in the execution path."
For example, if a critical CVE is disclosed in a widely used logging library (similar to the Log4Shell incident), a vendor whose product bundles that library but never enables the vulnerable JNDI lookup feature can publish a CycloneDX VEX statement marking the CVE as not_affected with the justification code_not_reachable. Downstream customers running automated SBOM analysis then see that finding automatically suppressed or de-prioritized, instead of triggering an emergency patch cycle for a vulnerability that was never actually exploitable in that context. This dramatically reduces the alert fatigue that plagues SBOM-driven vulnerability management.
Who Maintains the OWASP CycloneDX Standard?
The OWASP CycloneDX standard is maintained by the OWASP Foundation through a dedicated CycloneDX Core Working Group made up of security tool vendors, enterprise practitioners, and open-source maintainers who collaboratively govern the specification. The project publishes formal schema versions (the current major version is 1.6 as of this writing), maintains reference implementations, and coordinates with other standards bodies to keep the format aligned with regulatory guidance, including the U.S. National Telecommunications and Information Administration's (NTIA) minimum elements for SBOMs and CISA's software supply chain security guidance. Because it's community-governed rather than owned by a single vendor, CycloneDX has broad tool support: GitHub's native dependency graph, Dependency-Track, Anchore, Snyk, and most major CI/CD platforms can consume or emit CycloneDX documents natively.
This open governance model matters in practice. When a new class of software artifact needs representation — machine learning models, for instance — the working group can extend the schema (as it did with the ML-BOM extension) rather than forcing the entire ecosystem to wait on a single company's roadmap. That extensibility is a major reason CycloneDX adoption has grown quickly across cloud-native, embedded, and enterprise software teams alike.
How Safeguard Helps
Safeguard treats CycloneDX as a first-class input and output format across its software supply chain security platform, not an afterthought. Teams can ingest CycloneDX SBOMs generated anywhere in their build pipeline — from cdxgen, Syft, language-specific plugins, or third-party vendor disclosures — and Safeguard automatically normalizes them alongside SPDX documents, resolves PURLs against live vulnerability feeds, and flags newly disclosed CVEs against every affected component in real time. Rather than manually cross-referencing a fresh CVE against dozens of SBOMs, security teams get automatic, continuously updated exposure mapping the moment a new advisory is published.
Safeguard also helps organizations produce and consume CycloneDX VEX documents as part of a structured vulnerability response workflow: when your team determines a finding is not exploitable, Safeguard captures that decision as a proper VEX statement with justification codes, so the suppression is auditable, machine-readable, and automatically propagated to every downstream consumer of your SBOM — instead of living in a spreadsheet or a Slack thread. For organizations navigating compliance frameworks that reference SBOM requirements, Safeguard's reporting layer can generate audit-ready evidence showing which CycloneDX SBOM format fields are populated, where components lack license or provenance data, and how quickly VEX statements were issued after a new vulnerability disclosure — turning SBOM generation from a compliance checkbox into an operational security control.