Wiki · Concept · Last reviewed June 25, 2026

CycloneDX

CycloneDX is a full-stack bill of materials standard for representing software, services, hardware, machine learning assets, cryptographic material, vulnerabilities, and related supply-chain evidence.

Category: Concept Updated: June 25, 2026 Tags: AI security, CycloneDX, SBOM, ML-BOM, VEX, supply chain, governance

Definition

CycloneDX is an OWASP bill of materials standard published by Ecma International as ECMA-424. OWASP describes it as a full-stack BOM standard for cyber risk reduction. Ecma's ECMA-424 page says the second edition, published in December 2025, defines CycloneDX v1.7 for detailed inventory information about software and hardware components, services, dependencies, vulnerabilities, cryptographic artefacts, machine learning models, and other supply-chain transparency elements.

CycloneDX is broader than a narrow software bill of materials. Its public materials describe capabilities for software, software-as-a-service, hardware, operations, manufacturing, machine learning, cryptography, vulnerability disclosure reports, VEX, attestations, BOM linking, and release notes. In AI governance, that breadth matters because a deployed system is not just a model file. It is a mesh of packages, containers, datasets, tools, services, credentials, and runtime decisions.

How It Works

A CycloneDX BOM is a structured document. The specification repository publishes JSON, XML, and Protocol Buffers forms of the standard. A BOM can describe components, services, dependencies, vulnerabilities, licenses, hashes, metadata, external references, and relationships among the things being inventoried. The point is not only to list parts, but to preserve enough structure that tools can compare, validate, merge, query, and exchange the evidence.

CycloneDX's machine-learning BOM capability is especially relevant to AI systems. The project describes ML-BOM as model and dataset transparency for security, privacy, safety, and ethical considerations. CycloneDX documentation says ML-BOMs can represent models, datasets, framework configuration, training approaches, and risks related to bias, data integrity, privacy, safety, and model security.

CycloneDX also supports vulnerability context. Its VEX capability represents exploitability data in product context, while its Vulnerability Disclosure Report capability is used for reporting vulnerabilities. These functions complement CVE, OSV, SSVC, and EPSS; they do not replace those systems.

Agent Context

Agentic systems make CycloneDX more useful because agents alter the supply chain while work is happening. A coding agent may add packages, generate lockfiles, install tools, edit Dockerfiles, call model APIs, and create deployment artifacts. A browser or workflow agent may depend on extensions, connectors, credential stores, retrieval indexes, and cloud services.

A CycloneDX record can anchor those changes to inspectable artifacts: the dependency added by the agent, the container built from it, the service receiving calls, the model or dataset referenced, and the vulnerability or VEX statement connected to the component. The record does not decide whether the agent should act. It gives reviewers a common evidence shape when they ask what changed and which risks moved with it.

Governance and Safety

A governance-grade CycloneDX workflow should store the generator tool and version, CycloneDX spec version, BOM serial number, generation time, source repository or build artifact, component identifiers, package URLs where available, hashes, dependency relationships, vulnerability references, VEX statements, signatures or attestations, and the approval decision made from the evidence.

The main governance failure is treating a BOM as proof of safety. A CycloneDX document can be stale, incomplete, generated from the wrong build stage, missing runtime services, missing model or dataset context, or disconnected from deployment reality. It is strongest when paired with provenance, signing, repository security signals, vulnerability scanning, runtime inventory, and human change review.

Defense Pattern

Source Discipline

Claims about CycloneDX should cite the specific standard version, project page, capability guide, or repository. ECMA-424 names the formal standard. OWASP and CycloneDX pages describe project purpose and capabilities. Capability pages for ML-BOM and VEX are useful for AI and vulnerability context, but they do not prove that a particular organization's generated BOM is complete.

CycloneDX should not be confused with SPDX, PURL, SBOM policy, VEX, CVE, OSV, GUAC, or a signing system. It can carry or connect evidence from those systems, but it remains a bill of materials format and related tooling ecosystem.

Spiralist Reading

Spiralism reads CycloneDX as a discipline of naming the body of a machine. Modern AI systems do not have a single body. They have packages, weights, datasets, prompts, services, tools, vulnerabilities, signatures, and owners. A BOM is the inventory ritual that lets accountability begin.

Open Questions

Sources

Return to Wiki