When the SPDX project announced 3.0.1 on December 27, 2024, the release notes downplayed it as a "patch release" — typos, JSON-LD context fixes, a handful of property cardinality corrections caught during 3.0.0 implementation. The understatement obscured the real significance: 3.0.1 is the version SPDX submitted to the Object Management Group (OMG) for adoption as a formal OMG standard and the version that begins the fast-track route into ISO/IEC. For SBOM-format watchers, this is the maturation event that puts SPDX 3 on a parallel standards track with CycloneDX 1.6/1.7 (already ECMA-424). For practitioners, 3.0.1 is the version that production tools — Syft, FOSSology, Tern, Microsoft's SBOM Tool — should converge on through 2025 because it is the first stable, profile-complete 3-series release.
What was actually wrong with 3.0.0 that needed patching?
SPDX 3.0.0 shipped in April 2024 as the first major revision since 2.3 and introduced a sweeping architectural change: a Core model with optional profiles for Software, Build, Security, AI, Dataset, Licensing, and Lite. Implementers immediately hit three categories of issues. First, several profile-class definitions referenced properties that were declared without their cardinality bounds, which meant two conforming serializers could disagree on whether a field was an array or a single value. Second, the JSON-LD @context file embedded long-form IRIs that broke pyld and jsonld.js when the SBOM exceeded a few hundred elements. Third, the Build profile's relationship classes overlapped with the Software profile's Snippet semantics in a way that produced ambiguous round-trips through tag-value serialization. 3.0.1 closes all three classes of defects with edits that are non-breaking for compliant 3.0.0 documents.
What does the profile system look like in 3.0.1?
3.0.1 retains the Core + Profile architecture introduced in 3.0.0 and clarifies that a conforming SPDX document must declare its Core elements and may declare any subset of optional profiles. The seven optional profiles are:
| Profile | Purpose | Status in 3.0.1 | | --- | --- | --- | | Software | Traditional package and file inventory | Stable | | Build | Build process metadata, SLSA-style attestation hooks | Stable | | Security | CVE references, VEX statements, vulnerability assessments | Stable | | AI | Model cards, training data references, evaluation results | Stable | | Dataset | Dataset provenance, licensing, sensitive-content flags | Stable | | Licensing | Concluded versus declared licenses, expressions | Stable | | Lite | Minimal-element subset for constrained tooling | Stable |
A 3.0.1 producer chooses a profile combination and includes it in the document's profileConformance element. The Lite profile in particular is what tooling like SBOM-in-a-bottle CI plugins use to emit a CISA Minimum Elements-conformant document without carrying the full Software profile burden.
What does a minimal 3.0.1 document look like?
The canonical JSON-LD serialization for a single-package SBOM with Software and Security profiles:
{
"@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld",
"@graph": [
{
"spdxId": "urn:spdx:doc:example/sbom/2025-01-08",
"type": "SpdxDocument",
"creationInfo": {
"created": "2025-01-08T10:15:00Z",
"createdBy": ["urn:spdx:Agent:Tool:syft-1.17.0"],
"specVersion": "3.0.1",
"profileConformance": ["core", "software", "security"]
},
"rootElement": ["urn:spdx:Package:example-app-1.2.3"]
},
{
"spdxId": "urn:spdx:Package:example-app-1.2.3",
"type": "software_Package",
"name": "example-app",
"packageVersion": "1.2.3",
"primaryPurpose": "application",
"supplier": "urn:spdx:Organization:Example-Inc"
}
]
}
Note the software_ prefix on Package — profile classes are namespaced in 3.0.1's RDF/JSON-LD encoding to make the Core/profile boundary unambiguous. Tools that emitted bare Package against 3.0.0 must update their serializers, but the underlying semantic mapping is one-to-one.
How does 3.0.1 line up against OMG and ISO standardization?
The SPDX/3.0 specification was submitted to OMG in 2024 and is progressing through the OMG Adopted Specification process. The OMG submission references SPDX 3.0.1 — not 3.0.0 — because the patch release captured the edits OMG reviewers requested during the comment period. In parallel, the Linux Foundation has indicated SPDX will pursue ISO/IEC standardization on a track similar to the one that produced ISO/IEC 5962:2021 (which ratified SPDX 2.2.1). The ISO track typically takes 18–30 months from initial submission, so an ISO-blessed SPDX 3 designation is realistic in the 2026–2027 window.
What does migration from SPDX 2.3 look like in 3.0.1?
Migration is not automatic but is well-defined. SPDX 2.3 documents carry SPDXID, SPDXVersion: SPDX-2.3, and the flat package/file array structure. 3.0.1 replaces these with spdxId (IRI form), specVersion: "3.0.1", and the graph-based element model. The official spdx-tools Python package provides spdx-tools convert --from 2.3 --to 3.0.1 which preserves all components and relationships. The conversion lifts SPDX 2.3 Annotation records into Security profile VexStatement elements when the annotation type matches the VEX vocabulary. Producers running CI today should add a 3.0.1 emitter alongside their existing 2.3 output rather than cutting over; consumer support is still mixed through 2025.
Which tools support 3.0.1 in production?
The reference spdx-tools Python library shipped 3.0.1 in v0.9.0. FOSSology 4.5 emits 3.0.1 from its analysis pipeline. Syft added experimental 3.0.1 output in v1.16 and stabilized it in v1.18. Microsoft's SBOM Tool 4.0 (October 2025) emits 3.0.1 by default for new pipelines. The pyspdxtools and spdx-java-core libraries follow the canonical schema released alongside 3.0.1. Dependency-Track does not yet ingest SPDX 3-series natively — operators using DT should continue to ingest CycloneDX or run a 3.0.1-to-2.3 conversion at the boundary.
How Safeguard Helps
Safeguard parses SPDX 2.2, 2.3, and 3.0.1 with a single ingestion pipeline that promotes 2.x documents into the 3.0.1 graph model on the fly, so customers do not have to wait for upstream tools to standardize. The Security profile's VEX statements are merged with OpenVEX and CycloneDX-VEX documents into a unified vulnerability assessment graph that Griffin AI queries with natural language. AI profile elements — model identifiers, training data references — feed Safeguard's AI-BOM dashboard so customers preparing EU AI Act Article 10 evidence can demonstrate training data provenance directly from an SPDX 3.0.1 source. Policy gates can require a minimum profile set on any SBOM crossing a tier boundary, blocking, for example, a 3.0.1 document that omits the Build profile from being accepted as deployment evidence.