← CRA Glossary
Software Supply Chain

CycloneDX

CycloneDX is an open-standard SBOM format maintained by OWASP that represents software components, their relationships, and associated metadata in a machine-readable structure. It is one of the two dominant SBOM formats alongside SPDX and is widely used for CRA compliance documentation.

CycloneDX is an open-standard SBOM format maintained by OWASP that represents software components, their relationships, and associated metadata in a machine-readable structure. It is one of the two dominant SBOM formats alongside SPDX and is widely used for CRA compliance documentation.

Software Supply Chain

What Is CycloneDX?

CycloneDX is an open-standard Software Bill of Materials (SBOM) format maintained by the OWASP (Open Web Application Security Project) Foundation. It represents the components that make up a software product - including libraries, frameworks, operating system packages, and firmware - along with their versions, package URLs (PURLs), cryptographic hashes, and licence information. CycloneDX supports JSON, XML, and Protocol Buffers serialisation and is designed for machine-readable processing by vulnerability management tools, software composition analysis platforms, and supply chain security systems. CycloneDX goes beyond a pure inventory format: it explicitly supports VEX (Vulnerability Exploitability eXchange) documents, service dependencies, hardware component inventories, and cryptographic bill of materials (CBOM) - making it particularly comprehensive for CRA technical documentation purposes.

CRA reference:Annex VII

CycloneDX for CRA Compliance

The CRA's Annex VII requires manufacturers to include an SBOM in their technical documentation file. CycloneDX satisfies this requirement and provides capabilities that facilitate broader CRA compliance:

  • Component inventory: Lists all software components with versions and PURLs, supporting SBOM-based CVE correlation.
  • VEX integration: CycloneDX natively embeds VEX statements within the SBOM, allowing manufacturers to assert which CVEs do not affect the product - reducing alert noise for users.
  • License compliance: Tracks component licences, supporting intellectual property management alongside security obligations.
  • Hash verification: Cryptographic hashes for each component enable integrity verification, supporting the CRA's supply chain security requirements.
  • Composition completeness: CycloneDX includes a 'completeness' field indicating how thoroughly the SBOM captures all components, helping MSAs assess the file's reliability as evidence.
CRA reference:Annex VII, Annex I

CycloneDX vs SPDX: When to Use Each

CycloneDX and SPDX are both well-supported SBOM standards. Key differences:

  • Focus: CycloneDX emphasises security and vulnerability management - it has richer native support for VEX, services, and security-relevant metadata. SPDX emphasises licence compliance and provenance - it has deeper support for licence expression and copyright information.
  • Adoption: CycloneDX has strong adoption in the vulnerability management and PSIRT community. SPDX has stronger adoption in open source legal compliance contexts.
  • NTIA minimum elements: Both formats satisfy the US NTIA minimum SBOM elements; both are being considered for EU CRA compliance purposes.

For CRA compliance, CycloneDX is generally preferred for manufacturers whose primary SBOM use case is vulnerability management. SPDX is preferred when licence compliance is the primary driver. Many organisations generate both.

CRA reference:Annex VII

Tooling for CycloneDX Generation

CycloneDX SBOMs can be generated using open-source and commercial tooling:

  • Language-specific tools: The CycloneDX project maintains open-source plugins for Maven, Gradle, npm, Python pip, Go modules, .NET, and others - each capable of generating a CycloneDX SBOM for the respective language ecosystem's dependencies.
  • Container scanning: Tools such as Syft (Anchore) generate CycloneDX SBOMs from container images, capturing all OS packages and language dependencies in the image layer.
  • IDE integration: Many modern IDEs and CI/CD platforms integrate CycloneDX generation into build pipelines, enabling automatic SBOM generation on every release.
  • Dependency-Track: OWASP Dependency-Track natively consumes CycloneDX SBOMs and provides continuous vulnerability monitoring, making it a natural companion to CycloneDX generation tooling.

CVD Portal makes CycloneDX compliance straightforward.

Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.

Start your free portal

Frequently asked

Is CycloneDX the required SBOM format under the CRA?+

No. The CRA requires an SBOM in the technical documentation file but does not mandate a specific format. Both CycloneDX and SPDX are widely accepted. The choice of format should be driven by the manufacturer's tooling ecosystem and primary use cases. For vulnerability management workflows, CycloneDX is generally recommended. If a Notified Body is involved in assessment, confirming their preferred format is advisable.

Does CycloneDX handle firmware components, not just software libraries?+

Yes. CycloneDX supports hardware, firmware, and operating system components alongside software libraries and frameworks. For embedded products typical of CRA-covered IoT and industrial devices, CycloneDX can represent the full component stack: firmware, OS packages, application libraries, and external services. This comprehensive coverage makes it particularly suitable for the types of products that are the primary target of CRA regulation.

How often should a CycloneDX SBOM be regenerated?+

The SBOM should be regenerated on every product release that changes any component - a new dependency version, a removed library, or a new service dependency. The Annex VII technical file must reflect the current state of the product, so an outdated SBOM is a compliance gap. Best practice is to regenerate the SBOM automatically as part of the CI/CD build pipeline so that every release artefact has an accompanying, current SBOM without manual effort.

Related terms

Software Bill of Materials (SBOM)An SBOM is a formal, machine-readable inventory of all software components - including open-source libraries, third-party dependencies, and firmware packages - that make up a product. The EU Cyber Resilience Act requires manufacturers to maintain an SBOM as part of their technical documentation.SPDX (Software Package Data Exchange)SPDX (Software Package Data Exchange) is an ISO-standardised SBOM format (ISO/IEC 5962:2021) that describes software components, their versions, licences, and provenance in a machine-readable structure. SPDX is one of the two dominant SBOM formats alongside CycloneDX and is accepted for CRA technical documentation purposes.Package URL (PURL)A Package URL (PURL) is a standardised string format for uniquely identifying software packages across different package ecosystems. PURLs enable precise component identification in SBOMs, allowing vulnerability databases and security tools to reliably correlate SBOM entries with CVE records.VEX - Vulnerability Exploitability eXchangeVEX (Vulnerability Exploitability eXchange) is a machine-readable security advisory format that allows manufacturers to communicate the exploitability status of known CVEs in their products - specifically whether a CVE that appears in a component is actually exploitable in the context of how the component is used. VEX is essential for managing the false-positive burden of SBOM-based vulnerability scanning.Software Composition Analysis (SCA)Software Composition Analysis (SCA) is the automated process of identifying open-source and third-party components in a codebase and checking them against known vulnerability databases to detect security risks. SCA is the primary technical mechanism for meeting the CRA's requirement that manufacturers identify and manage vulnerabilities in their products' components.Dependency-TrackDependency-Track is an open-source Software Composition Analysis (SCA) platform maintained by OWASP that continuously monitors SBOM component inventories for known vulnerabilities. It is widely used by CRA manufacturers to operationalise their SBOM-driven vulnerability management obligations.

Sector checklists covering CycloneDX

Consumer Routers & ModemsConsumer routers and modems are high-value targets for attackers and face specific CRA requirements around default credentials, remote management security, and firmware update integrity. Routers marketed for home use are Default class; those marketed for industrial or critical infrastructure use may be Annex III Class II.Enterprise Networking EquipmentEnterprise networking equipment - switches, firewalls, load balancers, and network management systems - spans multiple Annex III classifications. Hardware firewalls are Class II Important products; network management software and monitoring tools are Class I Important products. Both require third-party conformity assessment.Embedded Linux DevicesEmbedded Linux devices span a vast range - from network gateways and industrial HMIs to set-top boxes and smart displays. All are products with digital elements subject to the CRA. The open-source nature of Linux creates specific obligations around SBOM completeness and CVE monitoring. Classification ranges from Default for consumer devices to Annex III Class I or II for industrial or infrastructure applications.Open Source HardwareOpen source hardware (OSH) projects occupy a unique position under the CRA. The regulation explicitly excludes hardware developed for non-commercial purposes, shared freely without monetisation. However, when open source hardware designs are manufactured and sold commercially - even by small businesses or community projects - the CRA's full scope applies. The CRA also introduces a 'steward' concept for open source projects that is relevant to OSH ecosystems. Understanding the commercial/non-commercial boundary is essential.

Browse the full CRA Compliance Checklist

See how CycloneDX fits into your complete CRA compliance programme.

View checklists →