OWASP CycloneDX is the international standard for bills of materials (ECMA-424), a machine-readable record of the components that make up a piece of software. This record, known as the Software Bill of Materials (SBOM), has become the basis of software supply chain transparency and is now used and consumed by more than 300 tools covering over 20 programming languages and is relied upon by industry and governments around the world.
CycloneDX 2.0, due this fall with Ecma International approval anticipated in December, develops the standard into a full language for supply chain transparency. The way a system is constructed, the threats to it, the measures that protect it, the actions it takes with data, the origins of its physical components, and the license that the organization is allowed to run all become data that travels between tools and organizations just as an SBOM does now.
Each of those is a full CycloneDX document in its own right. A threat model can exist on its own, and likewise a risk register, a privacy profile, a control inventory, and a signed attestation of conformity with a standard can each exist independently. They all use the same language, with the same method of identifying items, the same way of naming who made what claim, the same manner of presenting evidence, and the same way of signing the outcome. An inventory can be used to anchor any of these, and each of them can be used separately whenever that meets the requirements of the situation. This is the approach that has made the SBOM so widespread: it consists of simple documents, a common vocabulary, and only includes what is actually needed.
Threat Models That Leave the Tool
With CycloneDX 2.0, the threat models used by product security teams remain valid even after changes to tools, mergers, and vendors. The architecture of a system is provided as a blueprint that machines can examine, outlining the various zones, trust boundaries, data flows, and the assumptions upon which the design is based. Threat models developed using methodologies such as STRIDE, LINDDUN, PASTA, MAESTRO, and others, retain their meaning as they are transferred between different tools, teams, and suppliers. Risk is given consistent ratings in terms of inherent, residual, and target aspects. The controls are independent of one another, enabling governance teams to state just as clearly what protects the business as what threatens it. Analysis that would have disappeared with the expiration of a threat modeling tool license instead becomes an asset that the organization owns and can pass on to an acquirer, a customer, or an assessor.
Built for the Agentic Era
CycloneDX 2.0 includes verified intentions for coding agents regarding how to build. Business objectives are connected to the use cases that meet them, and use cases in turn are linked to the requirements that implement them, so an agent can understand the reason for the software rather than having to work out that reason from tickets and the commit history. The declared behavior specifies what an agent is allowed to do, which tools it may call, and where human approval is needed, while the observed behavior records what the delivered system actually does; an agent can even produce the record itself when the work is shipped, so that a test suite or an independent assessor can verify it. The security teams receive the opposite information: namely, what the agent is permitted to do, what it has been seen to do, and what it can access, all in a single, exchangeable record.
Post-Quantum Readiness as a Program
CycloneDX established the cryptographic bill of materials, and it is still the only bill of materials standard to include one. Version 2.0 transforms this inventory into a migration strategy. Each cryptographic asset can be assigned a risk, a response, an owner, a target date, and a status that senior management can check on a quarterly basis. Knowing an asset uses weak cryptography tells an organization it is exposed. Knowing that the asset encrypts data in transit rather than signing code helps organizations prioritize.
Privacy as Structured Data
The term ‘data profile’ has become part of the vocabulary used by privacy teams. A data profile lists the kinds of information that a product deals with, including biometric and genetic data as well as financial and health data; it sets out the purposes for which the data is used, the legal basis for each of those purposes, and the obligations associated with the data from the moment it is collected until it is disposed of. Those individuals who belong to legally protected categories can be identified as such, together with the jurisdictions and regulations that apply to them. Nowadays, privacy work that is carried out in the form of questionnaires and spreadsheets takes the form of data that both engineering staff, legal experts, and regulators can understand, and the entire data profile library constitutes a full CycloneDX document.
Provenance Down to the Raw Material
Hardware and manufacturing companies can go beyond the finished product and look at the material it is made from. The product specifies the materials it contains, the form and amount of these materials, as well as the origin of each material throughout all stages of the product’s lifecycle, starting with mining and smelting to manufacturing and assembly. The origin is given both by region and as a percentage, together with the name of the party that carried out each step. The certifications associated with the components accompany them. Questions regarding sourcing concentration, regulated materials, and the risk of supplier substitution can all be answered directly from the product record, which is precisely where procurement, compliance, and defense supply chain reviewers would like the answers.
The Whole License Portfolio
Companies license a great deal more software than open source compliance ever manages to cover. CycloneDX includes all this information in a single record: the name of the licensor, the name of the licensee, the purchaser, the purchase order number, the dates on which the license is renewed and expires, and 16 different types of commercial license, ranging from concurrent user to perpetual. No other bill of materials standard combines information about commercial entitlements and open source obligations. Legal teams can obtain evidence showing exactly which file and line contained the license, procurement receives the renewal information it can query, and asset management is given an inventory that now matches the contracts.
Claims That Show Their Work
Every determination in a 2.0 document carries its basis: the technique, the tool, the confidence, the location of the evidence, the timestamp, and the party asserting it. A supplier’s conclusion and an independent auditor’s sit side by side, each attributed by name. Consumers of advisories, auditors, and regulators calibrate trust instead of granting it.
Vulnerability Evidence
Vulnerability response teams are given advisories that they can consider rather than have to accept. When it is decided that a product is or is not affected, the analysis upon which that decision is based is included, specifying whether the conclusion was reached through a manifest scan, a reachability analysis, or a demonstrated exploit, the level of confidence attached to it, and the supporting evidence such as a request, a log, or a proof of concept. Each determination can be focused on a particular component or product.
This substantiates the Vulnerability Exploitability eXchange (VEX) assertions which at present take the form of general “not affected” statements based on the vendor’s word. In fact, the system even encourages disagreement: one supplier can state that a product is not affected while an independent party says it is, both claims being included in the same CycloneDX document, each one assigned to its author and supported by the author’s own evidence. Exploitability moves beyond a simple yes or no answer to an eight-point scale that ranges from the component being present to the attacker being able to reach it, and finally to the vulnerability having been exploited in the wild; there is also a separate rating for the maturity of known exploits. Instead of relying solely on severity scores, teams prioritize findings based on what an attacker can reach in their own deployment, and limited response time is directed toward the findings that warrant it.
Perspectives for Every Audience
Different industries read the same system through different vocabularies, and 2.0 serves all of them from one document. Perspectives present the parts that matter to a given audience, in that audience’s own terminology, across 82 named domains ranging from functional safety and medical devices to export control. A supplier serving several regulated markets publishes once. A regulation can specify the data it requires while using an existing format, which is exactly what policymakers have been asking for.
A Language for Files and APIs
CycloneDX 2.0 has two forms. In file form, it can be validated, signed, archived, and passed through build pipelines, procurement packages, and regulatory submissions. Files are well suited to these tasks, although one function has still never been carried out on a large scale: handing documents directly to every organization in the supply chain. The Transparency Exchange API (TEA) addresses this distribution challenge, allowing organizations to autonomously discover and share supply chain artifacts and intelligence.
The artifacts TEA distributes are the files themselves: SBOMs, cryptography bills of materials, CycloneDX Attestations, and every other document the language expresses. The intelligence comes from TEA’s insights capability: consumers ask the API questions, such as one product’s license position or a single vulnerability determination, and the answers come back in the CycloneDX 2.0 API format, a new specification introduced with this release. Transparency becomes a conversation as well as a record.
Start Anywhere
Simplicity has always been the CycloneDX design philosophy: a specification that is easy to adopt, easy to understand, and easy to implement, along with common-sense, practical implementation guidance. Version 2.0 applies that same philosophy to every new domain it covers. A minimal 2.0 document is just as small as a minimal 1.x document, every SBOM currently in production continues to work, and each new capability is additive. Getting started is just as easy as it has always been: an organization can adopt the language for a single use case, such as a threat model, a license inventory, or a privacy profile, and grow into as many more use cases as its needs require.
Coming This Fall
CycloneDX 2.0 is the result of two years of open working groups spanning hardware, blueprints, threat modeling, and cryptography, developed in partnership with multiple industries. Version 2.0 is expected this fall, with ratification by Ecma International following soon thereafter.
We can’t wait for you to try it!