SPDX has been the de facto standard for software package data exchange since its creation by the Linux Foundation in 2010. It became an ISO standard (ISO/IEC 5962:2021) with version 2.3, cementing its role in compliance and licensing workflows. But SPDX 3.0 is not an incremental update. It is a ground-up redesign that fundamentally changes how the specification works, and every team dealing with SBOMs needs to understand the implications.
The Problem SPDX 3.0 Solves
SPDX 2.x was originally designed for license compliance. It described packages, files, and the licensing relationships between them. When the industry began using SBOMs for security, SPDX 2.x was stretched to accommodate use cases it was never designed for. Vulnerability data, build provenance, and runtime context were either awkward to express or impossible.
SPDX 3.0 addresses this by introducing a modular, profile-based architecture that can describe not just software packages, but security metadata, build information, AI/ML models, and more -- all within a unified framework.
The Profile System
The biggest architectural change in SPDX 3.0 is the introduction of profiles. Instead of a monolithic specification, SPDX 3.0 is organized into modular profiles that can be adopted independently.
Core -- The base profile that defines the fundamental data model: elements, relationships, annotations, and identifiers. Every SPDX 3.0 document includes the core profile.
Software -- Describes software packages, files, snippets, and SBOMs. This is the closest analog to SPDX 2.x for teams doing traditional SBOM work.
Security -- A dedicated profile for vulnerability information, including VEX (Vulnerability Exploitability eXchange) data. This is a major upgrade from SPDX 2.x, where security data was effectively bolted on.
Licensing -- License expressions, declared vs. concluded licenses, and licensing relationships.
Build -- Describes how software was built, including build tools, environments, and parameters. Similar in intent to CycloneDX's formulation concept.
AI/ML -- Metadata for machine learning models, datasets, and training pipelines.
Lite -- A minimal profile for scenarios where only basic identification data is needed, such as embedded systems or constrained environments.
This modularity is significant because it means organizations can adopt exactly the profiles they need. A legal team doing license compliance does not need the security profile. A security team doing vulnerability management does not need the licensing profile. And tooling can declare which profiles it supports, reducing interoperability confusion.
The New Data Model
SPDX 2.x used a document-centric model: you had an SPDX document that contained packages and files with relationships between them. SPDX 3.0 moves to an element-centric model built on linked data principles.
Everything in SPDX 3.0 is an Element. Elements have a globally unique identifier (a SPDX ID that is a URI), a creation timestamp, and one or more creators. Elements are connected through Relationships, which are themselves Elements -- meaning relationships can have their own metadata, creation info, and annotations.
This sounds abstract, but the practical impact is significant:
Cross-document linking. In SPDX 2.x, referencing a package defined in another SPDX document was cumbersome. In 3.0, because every element has a URI, you can reference any element from any document simply by using its identifier. This enables distributed SBOM architectures where suppliers provide their own SPDX documents and consumers link to them.
Richer relationships. SPDX 3.0 defines a much larger set of relationship types, including security-specific relationships like "has assessed vulnerability" and "has VEX statement." Relationships can also carry completeness assertions, indicating whether the relationship is known-complete or known-incomplete.
Temporal data. Elements carry creation timestamps, and the model supports versioning. This means you can track how an SBOM evolves over time, which is critical for audit trails and incident response.
VEX Integration
One of the most anticipated features of SPDX 3.0 is native VEX support through the security profile. VEX documents communicate the exploitability status of vulnerabilities in specific products.
In SPDX 3.0, a VEX statement is modeled as a relationship between a vulnerability element and a product element, with a status that can be:
- Not affected: The product is not affected by the vulnerability
- Affected: The product is affected and action is required
- Fixed: The vulnerability has been remediated in this version
- Under investigation: The vendor is still assessing impact
Each status can include justification text, timestamps, and references. This is a substantial improvement over the ad-hoc approaches teams used with SPDX 2.x, and it aligns with CISA's VEX guidance.
Serialization Formats
SPDX 2.x supported tag-value, RDF/XML, JSON, YAML, and spreadsheet formats. SPDX 3.0 simplifies this to focus on JSON-LD as the primary serialization format, with support for other RDF serializations through the linked data foundation.
JSON-LD was chosen because it is both human-readable JSON and machine-processable linked data. This means an SPDX 3.0 document can be consumed by standard JSON parsers (for simple use cases) or by RDF processors (for advanced querying and reasoning).
The practical implication is that teams working with SPDX 3.0 should get comfortable with JSON-LD. The learning curve is modest if you already work with JSON, but the linked data aspects (contexts, compact IRIs) add some complexity.
Migration from SPDX 2.x
The migration path from SPDX 2.x to 3.0 is not trivial. The data model is different enough that automated conversion is possible for basic cases but requires human review for complex documents.
Key migration considerations:
- Package and file elements map relatively cleanly to SPDX 3.0 Software elements
- License expressions are largely compatible but now live in a dedicated profile
- External document references are replaced by the URI-based linking model
- Custom annotations and relationships may need to be remapped to new types
Tooling support for SPDX 3.0 is still maturing. As of mid-2024, some major SBOM generators support 3.0 output, but many enterprise tools still default to 2.3. Plan for a transition period where you may need to support both versions.
What This Means for the SBOM Ecosystem
SPDX 3.0 narrows the gap between SPDX and CycloneDX significantly. With native security profiles, VEX support, and build provenance, many of the features that previously differentiated CycloneDX are now available in SPDX as well. The remaining differences are largely architectural (linked data vs. flat document) and philosophical (standards-body-driven vs. community-driven).
For organizations, this means the choice between SPDX and CycloneDX is increasingly about ecosystem fit rather than capability gaps. Both are converging on a similar feature set, and tooling interoperability between them continues to improve.
How Safeguard.sh Helps
Safeguard.sh supports both SPDX 2.3 and SPDX 3.0, including the security profile with VEX data. When you upload an SPDX 3.0 document, Safeguard.sh resolves cross-document references, processes VEX statements to adjust vulnerability status, and normalizes the data alongside CycloneDX BOMs in a unified view.
This means you do not need to standardize on a single SBOM format across your supply chain. Suppliers can provide BOMs in whichever format their tooling supports, and Safeguard.sh handles the normalization. As the ecosystem transitions from SPDX 2.x to 3.0, Safeguard.sh provides a consistent interface regardless of which version your suppliers are generating.