CRA SBOM Requirements: SPDX vs CycloneDX vs SWID — Which Format Wins? (mis à jour 07/2026)

Mise à jour du 31 juillet 2026. Les *2026 Minimum Elements for a SBOM* v2.1, publiés le 29 juillet 2026 par la CISA avec l'ANSSI, le BSI et 14 autres agences nationales, retirent SWID de la liste des formats de données SBOM reconnus — le motif avancé étant l'absence d'outillage suffisant. La comparaison à trois formats ci-dessous n'est donc plus d'actualité : le choix se joue désormais entre SPDX et CycloneDX. Cette mise à jour ne disqualifie PAS les balises SWID comme *identifiants de composant* : l'élément Component Identifiers accepte explicitement les identifiants propres à une organisation et les identifiants intrinsèques. Ce qui disparaît, c'est SWID comme format du document SBOM, pas comme moyen d'identifier un composant à l'intérieur. Autres changements du même texte : Supplier Name devient Component Producer, l'élément Access Control est supprimé, et sept champs apparaissent — dont SBOM Author Signature et SBOM Timestamp.

The Cyber Resilience Act (CRA) mandates that manufacturers of digital products provide a machine-readable software bill of materials (SBOM) for every release. Annex I.2(1)(d) leaves the format open, but the choice carries long-term compliance, interoperability, and cost consequences. This article compares SPDX, CycloneDX, and SWID against the CRA’s requirements, maps them to the NTIA minimum elements, and recommends tooling for each major ecosystem.

---

1. CRA Annex I.2(1)(d) SBOM mandate: what ‘machine-readable’ actually means

The CRA does not prescribe a specific format, but the term “machine-readable” in Annex I.2(1)(d) implies three technical constraints:

• Structured syntax: JSON, XML, YAML, or tag-value pairs that parsers can ingest without manual intervention.
• Standardised semantics: A published schema or specification that defines fields such as component name, version, supplier, and licence.
• Unique identifiers: CPE, PURL, or SWID tags that enable automated vulnerability matching against sources like the NVD or ENISA’s vulnerability database.

The European Commission’s delegated acts (expected Q4 2025) may further clarify whether the SBOM must be embedded in the product (e.g., as a SWID tag) or delivered as a separate file. Until then, manufacturers must choose a format that satisfies both the CRA and the NTIA’s *Minimum Elements for a Software Bill of Materials* (2021), which the Commission has informally endorsed.

---

2. Comparison matrix: SPDX 2.3 vs CycloneDX 1.6 vs SWID Tags

SPDX and CycloneDX both satisfy the CRA’s “machine-readable” requirement and the NTIA’s minimum elements. SWID tags are mandated by the US *NTIA SBOM Minimum Elements* for firmware and Windows applications, but their lack of a dependency graph makes them insufficient for most CRA-covered products.

---

3. Sample SBOM excerpts

CycloneDX 1.6 JSON (minimal)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "supplier": {
        "name": "OpenJS Foundation"
      }
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:npm/lodash@4.17.21",
      "dependsOn": []
    }
  ]
}

SPDX 2.3 YAML (minimal)

SPDXID: "SPDXRef-DOCUMENT"
spdxVersion: "SPDX-2.3"
creationInfo:
  created: "2024-10-15T00:00:00Z"
  creators:
    - "Tool: spdx-sbom-generator"
name: "example-app"
dataLicense: "CC0-1.0"
packages:
  - SPDXID: "SPDXRef-Package-lodash"
    name: "lodash"
    versionInfo: "4.17.21"
    downloadLocation: "NOASSERTION"
    licenseConcluded: "MIT"
    supplier: "Organization: OpenJS Foundation"
    externalRefs:
      - referenceCategory: "PACKAGE-MANAGER"
        referenceType: "purl"
        referenceLocator: "pkg:npm/lodash@4.17.21"

Both excerpts include the NTIA minimum elements: supplier, component name, version, unique identifier (PURL), and licence. CycloneDX’s built-in dependencies array is more concise for dependency graphs; SPDX’s relationships section offers finer granularity but requires more tooling.

---

4. Generation tooling per ecosystem

Recommendation: Use @cyclonedx/bom for npm, cyclonedx-maven-plugin for Maven, and syft for container images. These tools are actively maintained, support both formats, and integrate with vulnerability disclosure workflows.

---

5. Vulnerability disclosure integration

The CRA requires manufacturers to disclose vulnerabilities “without undue delay” (Article 13(1)). SBOMs alone do not convey exploitability; Vulnerability Exploitability eXchange (VEX) documents are needed.

CycloneDX’s built-in VEX support simplifies compliance: a single JSON file can contain both the SBOM and the VEX statements. SPDX requires a separate VEX document, typically in CSAF or OpenVEX format.

Tooling:

• vexctl (OpenVEX) for SPDX.
• cyclonedx-cli for CycloneDX VEX.
• csaf-tools for CSAF.

---

6. Storage and retention: 10-year obligation vs practical lifecycle

The CRA requires manufacturers to retain SBOMs for 10 years after the product ceases to be supported (Annex I.2(1)(d)). This exceeds typical cloud storage retention policies and necessitates a dedicated SBOM repository.

Storage options

Retention workflow

1. 1Generation: SBOM generated at build time (GitHub Actions, GitLab CI, Jenkins).
2. 2Signing: SBOM signed with Sigstore or PGP (CRA Annex I.2(1)(e)).
3. 3Storage: Pushed to object storage + SBOM platform.
4. 4Retention policy: Object storage lifecycle rule to archive after 1 year, delete after 10 years.
5. 5Access control: IAM policies restrict access to compliance and security teams.

Recommendation: Use a dedicated SBOM platform (e.g., Dependency-Track, FOSSA, or NexCyber) for search and VEX integration, and object storage for long-term retention.

---

Next step with NexCyber

The CRA’s SBOM mandate is not a one-time deliverable