SPDX

SPDX is an open exchange format for software bills of materials. It grew out of work at the Linux Foundation, initially aimed at making licence information about software components machine-readable. The ambition to carry a full component inventory came later.

The Cyber Resilience Act (CRA) never mentions SPDX. There is no provision to cite. Annex I, Part II, point 1 asks only for “a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Which formats count as commonly used is left open.

The obligation itself belongs to the Software Bill of Materials (SBOM). What follows is the practical question that comes next: does SPDX serve that duty, what does it cover, and where does it stop?

Why SPDX meets the requirement

The provision demands two properties of the format, and SPDX has both. It is machine-readable in every serialisation it offers, with JSON and YAML the usual choices today. It counts as commonly used not least because version 2.2.1 was standardised as ISO/IEC 5962 in 2021.

That standardisation is more than a footnote under the CRA. Article 13(24) lets the Commission specify the format and elements of the software bill of materials by implementing act, expressly “taking into account European or international standards and best practices”. No such act exists yet. If one arrives, a format already standardised internationally is an obvious reference point.

What an SPDX document describes

An SPDX document is more than a list of components. It is made up of several sections:

• Document information: who produced the bill of materials, with which tool, and when. Without it, nobody can later establish which state a document describes.
• Packages with name, version, supplier, download location and checksums. Most analysis happens at this level.
• Files and snippets down to individual line ranges. That makes SPDX useful where third-party code was copied into your own files.
• Licence data, kept apart for what the project declares and what an analysis concluded.
• Relationships between those elements. SPDX defines several dozen relationship types and so distinguishes a contained component from a statically linked, dynamically loaded or build-only one.
• External identifiers, above all Package URLs and CPE names. They are the hook for automated matching against vulnerability databases.

The supply chain relationships that the legal definition of a software bill of materials expressly names are therefore native to SPDX. Exporting a flat package list uses a fraction of the format.

Versions and serialisations

Three releases turn up in practice. SPDX 2.2.1 is the standardised one, SPDX 2.3 the most widely produced, and SPDX 3.0, published in 2024, the redesign. Version 3.0 is not an increment but a new data model: content is split into profiles covering software, licensing, security, build and AI among others, and JSON-LD carries the serialisation.

Tools and recipients are moving across slowly. Before committing to a version, ask what the receiving side actually parses. For supply chains that only want to exchange a small core of fields, there is also the deliberately reduced SPDX Lite profile.

Where SPDX stops

Vulnerabilities are not part of it. The 2.x versions have no data model of their own for vulnerabilities and no fields for a statement about exploitability. Only the security profile in version 3.0 brings both. To record today that a component is present but the vulnerability inside it is not reachable, you carry that in a separate VEX document.

Formal validity says nothing about completeness. SPDX allows the value NOASSERTION in many fields and lets a producer state that files were not analysed at all. A document can pass every schema check and still assert almost nothing. The Annex I requirement is measured by content, not by schema.

The format generates nothing. Whether transitive dependencies are captured at all is decided by the generation step in your build, not by the choice between two formats.

How it relates to CycloneDX

Alongside SPDX, CycloneDX has established itself as the second commonly used format, with a different origin and a different emphasis. Both satisfy Annex I, Part II, point 1. The choice is therefore a question of the tooling you run and what your customers expect, not a legal one.

What counts under the CRA

Annex VII, point 8 counts the software bill of materials as part of the technical documentation, where applicable, further to a reasoned request from a Market surveillance authority and only provided that it is necessary for that authority to check compliance with the essential cybersecurity requirements set out in Annex I. There is no duty to publish it. If you nonetheless decide to make it available to users, Annex II, point 9 requires the user information to state where it can be accessed.

What the authority then looks at is whether the document shows the components built in, with version and origin. That it has to be SPDX is not something the regulation says.