CycloneDX specification: a BOM format that is also an Ecma standard
OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX
At a glance
- What is it?
- CycloneDX is a Bill of Materials format maintained by OWASP and Ecma TC54, with schemas in XML, JSON and Protocol Buffer. It is a data format and a schema repository, not a scanner, and adopting it means writing or wiring up generators yourself.
- Who is it for?
- Adopt CycloneDX if you need one format that covers software components, services, hardware, ML models, cryptography, VEX and attestations, and you have engineering capacity to produce or consume the schemas yourself. Do not adopt it expecting a ready-made scanner: this repository ships schemas, not tooling.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly XSLT, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the CycloneDX specification repository actually is
The repository is the normative definition of a data format, not an application. Its primary language is XSLT, which tells you what kind of artefact lives here: schema documents, transforms and documentation build steps rather than a runtime library. The README states that the CycloneDX schemas in the repository are the official interpretations of the standard and that the JSON Schema is the reference implementation for the standard. That sentence matters more than any other in the file. If JSON and XML disagree about a field, the JSON Schema is the document the project points to as authoritative.
The standard itself is published by Ecma International as ECMA-424, and the README notes that the OWASP Foundation and Ecma TC54 drive its continued advancement. This is the structural difference between CycloneDX and a project-specific export format. A vendor can change its own JSON at any release; changing ECMA-424 involves a standards committee. For an organisation that has to defend a format choice to an auditor or a customer, that provenance is the argument. For an organisation that just wants to dump a dependency list, it is overhead with no immediate payoff.
The scope is deliberately wider than software. The README lists SBOM, SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM, VDR, VEX and CycloneDX Attestations (CDXA) as supported document types. One schema family is meant to describe a container image, a hosted service, a model checkpoint, a cryptographic algorithm inventory and a vulnerability disclosure in the same vocabulary. Whether that breadth is a strength or a source of confusion depends entirely on how many of those document types you actually produce.
The problem it solves, and who feels it
The problem is that supply chain data arrives in incompatible shapes. A build system knows its direct dependencies. A container scanner knows its OS packages. A procurement system knows which vendor services are in use. A security team knows which CVEs are exploitable. Without a shared document format, each of those facts stays in its own tool and the correlation work is manual.
CycloneDX's answer is to define one schema family with a component model at the centre and extensions for the other domains. The intended audience is tool builders and platform teams, not individual developers. The README points to a Tool Center described as a community effort to establish a marketplace of free, open source, and proprietary tools and solutions that support the specification. That is the practical entry point for most adopters: you pick a generator from that list rather than writing serialisation code.
There is a second audience that is easy to overlook. Because the format covers VEX and VDR, it is also aimed at the disclosure side of the relationship, meaning a vendor publishing exploitability statements about its own products. A team that only needs an SBOM for its own services is using a fraction of the specification, and should be honest about that when comparing it to narrower formats.
How the schema, media types and file naming fit together
The data flow is straightforward once you separate the two halves. On the producing side, a tool reads a build environment or an image and emits a document conforming to one of the schemas. On the consuming side, a scanner, a policy engine or a warehouse parses that document. The specification repository sits in the middle and defines what both sides must agree on.
Identification happens at three levels. IANA-registered media types carry the format: application/vnd.cyclonedx+xml and application/vnd.cyclonedx+json are both registered, and the README lists application/x.vnd.cyclonedx+protobuf for Protocol Buffer without an IANA assignment. Version selection rides on a parameter, with the README giving application/vnd.cyclonedx+xml; version=1.6 as the example. That parameter is where interoperability breaks in practice. A consumer that ignores it will happily accept a 1.7 document and then fail on a field it does not know.
File naming is conventional rather than enforced. The README states that bom.json and bom.xml are the conventional names, and that files matching *.cdx.json or *.cdx.xml are also recognized. In a repository with several BOMs, the glob forms are the more useful convention because they survive being renamed or moved into a subdirectory. The repository also carries CI workflows for documentation builds and for conformance testing against Java, JavaScript, PHP and Protocol Buffer implementations, which is how the project checks that the schemas are implementable in more than one language.
Getting a valid document without installing the specification
There is nothing to install from this repository to produce a BOM. The repository publishes schemas; you obtain a document by running a generator that targets them. The commands below are the ones the material supports, and they assume a generator is already present in your environment.
To validate a JSON BOM against the reference schema, fetch the schema for the version you target and point a validator at it, for example ajv validate -s cyclonedx.schema.json -d bom.json. For XML, xmllint --noout --schema cyclonedx.xsd bom.xml performs the equivalent check. Neither command is defined by the specification itself; they are the ordinary validators for those formats, and the schema files are what you feed them.
For transport, set the content type explicitly. A JSON BOM served over HTTP should carry application/vnd.cyclonedx+json, and the version parameter should be added when the consumer needs a specific revision. When you store documents, prefer the glob-recognised names: a file called service-a.cdx.json is self-identifying, while bom.json in a directory of several BOMs is not. Before publishing anything, check the release history table in the README and confirm which schema version your generator emits, because the three most recent tagged releases in this repository are 1.7.1, 1.6.2 and 1.5.1, all dated 2 June 2026, and those are maintenance releases on three parallel version lines rather than a single sequence.
Where the specification stops and your tooling has to start
The most common misreading of this project is treating it as a scanner. It is not. The README describes a standard and a schema repository; it does not describe a discovery engine. If you need to know what is inside a container image or a compiled binary, that capability comes from a tool in the Tool Center or from something you build, and the specification only constrains the output shape.
A second limit is breadth. Ten document types in one schema family means the schema is large, and a generator that supports SBOM well may support CBOM or ML-BOM poorly or not at all. Nothing in the repository forces a tool to implement every branch. When you evaluate a generator, the useful question is which document types and which schema version it emits, not whether it says it supports CycloneDX.
A third issue is the multi-version release pattern. Three version lines receiving maintenance releases on the same day means the ecosystem is not converging on one revision. A consumer built for 1.6 will meet 1.5 and 1.7 documents in the same pipeline. The version parameter in the media type exists precisely for this, but it only helps if both ends honour it. This is a real cost of adopting a standard with a long support tail, and it is not something the repository can solve for you.
CycloneDX against SPDX, and when the other format wins
SPDX is the obvious alternative and it appears in this repository's own topic list, which is a fair signal that the two are compared constantly. The difference in approach is about what the document is for. SPDX grew out of licence compliance and file-level provenance, so its centre of gravity is what is in a package and under what terms. CycloneDX grew out of application security and its centre of gravity is the component and its risk context, which is why VEX, VDR and attestations sit inside the same family rather than in a companion document.
That difference shows up in concrete choices. CycloneDX uses IANA-registered media types with a version parameter, which makes it natural to negotiate over HTTP. It offers three serialisations including Protocol Buffer, which matters if you are moving large inventories between services. SPDX has its own identifier scheme and a different document model, and for a pure licence-compliance workflow it is a reasonable default.
Where SPDX wins is when your only requirement is licence inventory and your consumers already speak it. Where CycloneDX wins is when you need exploitability statements, service or hardware inventories, or cryptographic inventories in the same pipeline as your software components. Choosing both is also legitimate, and more common than either camp admits, but it doubles the generation and validation surface you have to maintain.
Maintenance cost, licensing and what to check before you commit
The schemas in the repository are Apache-2.0, and the README states that the standard is published under a royalty-free patent policy through Ecma. For most adopters the practical consequence is that implementing the format, including in a commercial product, is not gated by licensing. This is a description of what the repository says, not legal advice; if you are embedding the schemas in a distributed product, read the Apache-2.0 text and the Ecma policy yourself.
The maintenance burden is not in the schema files. It is in the version matrix. With 1.5.1, 1.6.2 and 1.7.1 all maintained, a producer has to decide which line to emit and a consumer has to decide which lines to accept. The release history in the README stretches back to an initial prototype in May 2017 and a 1.0 in March 2018, so documents from several generations are plausibly still in circulation. Budget for a compatibility decision rather than a one-time upgrade.
Before adopting, verify three things against your own tooling. First, which schema version your generator emits and whether it can be pinned. Second, whether your consumer honours the version parameter on application/vnd.cyclonedx+json, since ignoring it is the quiet failure mode. Third, whether the document types you need (VEX, CBOM, ML-BOM) are actually implemented by the tools you plan to use, rather than merely listed as supported by the specification.
Editorial conclusion
Adopt CycloneDX if you need one format that covers software components, services, hardware, ML models, cryptography, VEX and attestations, and you have engineering capacity to produce or consume the schemas yourself. Do not adopt it expecting a ready-made scanner: this repository ships schemas, not tooling. Before committing, confirm which schema version your generators emit and whether your consumers accept application/vnd.cyclonedx+xml; version=1.6, because a mismatch between generator output and consumer expectation is the failure you will actually hit.
Community notes