SPDX 3.0, explained: what changed for SBOMs

SPDX 2.x described a software package as a single, mostly flat document: one file listing packages, files and their relationships in a fixed schema. SPDX 3.0 rebuilds that as an RDF-based graph of Elements — independently identified nodes, each carrying its own IRI (spdxId) — connected by first-class Relationship objects that the spec defines as "a grouping of characteristics unique to an assertion that one Element is related to one or more other Elements in some way." Because the underlying model is RDF, SPDX 3.0 data can be serialized as JSON-LD (the format's canonical, most commonly used form), Turtle, N-Triples or RDF/XML — the spreadsheet and tag-value serializations that existed in 2.x are not carried forward into 3.0, and tooling that only speaks 2.x tag-value will need an upgrade path, not just a version bump.

SPDX 3.0's conformance page defines nine compliance points called Profiles: Core, Software, Security, Licensing, Dataset, AI, Build, Lite and Extension — with Core mandatory as the foundation every other profile builds on ("conformance to the Core Profile compliance point is mandatory for all other SPDX profiles"). In practice this means a given SPDX 3.0 document declares which profiles it conforms to, and a consumer can check for exactly the information it needs — software composition via the Software profile, licensing via Licensing, vulnerability data via Security — rather than parsing one undifferentiated schema for everything.

The Security profile is where SPDX 3.0 picks up ground CycloneDX had already staked out with VEX support. Per the spec, it "captures security related information," and the project's own security page describes its purpose as "exchanging information about system vulnerabilities that may exist, the severity of those vulnerabilities, and a mechanism to express how a vulnerability may affect a specific element including if a fix is available." Concretely, it defines a Vulnerability class plus four concrete relationship types mapped one-to-one onto standard VEX statuses — affected, not_affected, fixed and under_investigation — alongside relationship types carrying CVSS v2/v3/v4 scores, EPSS scores, and CISA's Stakeholder-Specific Vulnerability Categorization (SSVC). That gives SPDX 3.0 roughly the same VEX expressiveness our guide to CSAF VEX for device makers covers for the CSAF/OpenVEX side of the ecosystem, now inside the SBOM document's own data model rather than a separate attached statement.

SPDX 3.0 also ships a dedicated AI profile, defined around an AIPackage class with properties including autonomyType, domain, hyperparameter, limitation, metric, modelExplainability, safetyRiskAssessment, standardCompliance and typeOfModel, plus EnergyConsumption fields for training, fine-tuning and inference energy use. A companion Dataset profile defines a DatasetPackage class for the training/validation data itself. For a device maker embedding a model in firmware, this is a genuinely new capability — SPDX 2.x had no standard place to declare "this component is a model, trained this way, with these limitations" — and it overlaps directly with the gap our guide to AI-BOM for embedded AI devices describes; whether a given toolchain actually populates these AI-profile fields today, versus treating an embedded model as an opaque binary blob, is still the practical question to check before relying on it.

Not yet, on the ISO question: ISO/IEC 5962:2021 standardizes SPDX version 2.2.1, not 3.0, and a successor ISO draft covering 3.0 was still in ballot as of this guide's research date — worth re-checking the ISO catalogue directly before calling SPDX 3.0 "ISO-standardized" in a compliance document. On CycloneDX: the two formats coexist rather than one replacing the other. OpenSSF stated in October 2025 that "OpenSSF's strategic support for both standards – SPDX and CycloneDX – is vital for the entire ecosystem," citing translation tooling (Protobom, BomCTL) built specifically so organizations aren't "forced to choose between SPDX and CycloneDX." Our guide to CycloneDX vs. SPDX SBOM formats covers the practical tradeoffs between the two in more depth; SPDX 3.0's main effect on that comparison is narrowing the gap on vulnerability/VEX expressiveness, an area where CycloneDX previously had the more mature feature set.

Tooling support is uneven and worth checking per-tool rather than assuming. Microsoft's open-source sbom-tool can generate SPDX 3.0-conformant output, with Microsoft's Adrian Diglio quoted in the Linux Foundation's announcement saying the company has "been a long partner and contributor to the next gen SPDX schema" — but Anchore's widely used Syft scanner did not yet support SPDX 3.0 output as of this guide's research date, with 3.0 support tracked as an open feature request. A device maker asked for "an SBOM" today should confirm whether a counterparty specifically wants SPDX 3.0's profile-based JSON-LD, SPDX 2.x's tag-value or JSON, or CycloneDX — the formats are not interchangeable without a translation step, even within SPDX's own version history.

SoftWSP generates firmware SBOMs directly from binary images — without needing build-time source access — and can target the SBOM format (SPDX 2.x, SPDX 3.0 where a toolchain and counterparty both support it, or CycloneDX) a given customer or regulator actually asks for. See device & firmware security services for how that SBOM generation fits into a broader firmware assessment.

This guide is based on the official SPDX 3.0.1 specification pages (spdx.github.io/spdx-spec/v3.0.1/), the Linux Foundation's April 2024 announcement, the ISO catalogue listing for ISO/IEC 5962:2021, and OpenSSF's October 2025 blog post on SPDX/CycloneDX coexistence, all fetched directly for this guide. Tooling-support claims (Microsoft sbom-tool, Syft) reflect the state of each project's public repository as of the research date and may have changed since; check each tool's own documentation before relying on a specific format being supported.