SPDX 3.0 has been the de facto SBOM specification for any organization working with AI components since its publication, and the 3.0.1 patch in late 2025 cleaned up the rough edges that were blocking enterprise adoption. The format is now stable enough to commit to, the tooling has caught up across the major SBOM generators and consumers, and the ISO/IEC submission process is on track. This post is an honest summary of what changed from SPDX 2.3, what is genuinely new in 3.0, and how to think about migration.
We are not going to recap every section of the spec. The interesting part of SPDX 3.0 is structural: it is a fundamentally different document model than SPDX 2.3, and the implications of that shift drive most of the practical decisions teams make about adoption.
What is the profile model and why does it matter?
SPDX 3.0 organizes capabilities into profiles. The Core profile is mandatory and contains the identification, relationships, and provenance primitives. Optional profiles include Software, Licensing, Security, Build, AI, Dataset, Lite, and Extension. A given SPDX 3.0 document declares which profiles it conforms to, and consumers can decide which profiles they require and which they will ignore.
This matters because it lets the spec evolve different domains at different speeds without forcing every consumer to handle every feature. An AI/ML team can produce documents that conform to Core, Software, and AI profiles, and a downstream consumer that only cares about traditional software dependencies can ignore the AI profile entirely. The previous all-or-nothing model in SPDX 2.x forced complexity onto consumers that did not need it, and the profile model is the single most consequential structural change in 3.0.
What changed in the AI and Dataset profiles?
The AI profile in 3.0.1 reached the maturity needed for production use. It defines AIPackage as a distinct element type with required fields for model architecture, training methodology, intended use, and a structured set of safety risk categories drawn from the NIST AI Risk Management Framework. Energy consumption, model size, and hyperparameter capture are all standardized rather than left as freeform metadata. For organizations producing AIBOMs, this is the spec to target, and the OWASP AIBOM working group has aligned its recommendations to it.
The Dataset profile parallels the AI profile but for training data. It captures dataset provenance, sensitive-content flags, licensing, anonymization status, and intended use restrictions. The pairing of AI and Dataset profiles in a single document model is what makes SPDX 3.0 viable for the EU AI Act Article 10 data governance requirements, which require traceable provenance of training data for high-risk AI systems. That regulatory alignment is the practical reason most enterprise AI teams are migrating to 3.0 rather than staying on 2.3 with vendor extensions.
What about serialization formats?
SPDX 3.0 standardized on JSON-LD as the primary serialization, with the older formats deprecated. The motivation is interoperability with the broader linked-data ecosystem and a cleaner namespace and identifier model. In practice, JSON-LD adds verbosity compared to plain JSON and a learning curve for engineers who have not worked with it. The standard ships explicit framing rules that let you produce documents that are valid JSON-LD and also reasonable to read as plain JSON, which mitigates most of the ergonomic concern.
The tag-value, RDF/XML, and YAML serializations from SPDX 2.3 are formally deprecated in 3.0. Tools that emit those formats are operating in a 2.3 backward-compatibility mode and you should treat their output as legacy. New tooling, including the latest Syft, Trivy, and CycloneDX-to-SPDX converters, emits JSON-LD by default and that is the format to standardize on.
What is the Build profile and how does it relate to SLSA?
The Build profile captures the build environment, the build steps, and the inputs that produced an output element. It maps cleanly to SLSA provenance, and SLSA 1.1 provenance documents can be losslessly expressed as SPDX 3.0 Build profile content. This is significant because it removes the previous awkwardness of carrying SBOM and SLSA provenance as two separate documents that referenced each other through external identifiers.
For organizations targeting SLSA Level 3 or 4, the Build profile lets you produce a single signed SPDX 3.0 document that satisfies both SBOM and provenance requirements. That reduces tooling complexity and removes the synchronization problem of keeping SBOM and provenance documents consistent. Several CI vendors, including GitHub and GitLab, ship native SPDX 3.0 Build profile output in their latest releases.
How should you sequence the migration?
The migration order that works is: producers first, consumers second, policy third. Start by upgrading your SBOM generators to versions that emit SPDX 3.0 alongside the existing 2.3 output. Run both for a release cycle to validate consistency. Then upgrade your consumers, primarily scanners, policy engines, and dependency-tracking systems, to accept 3.0. Finally, update your policy rules to take advantage of the new profile-aware fields, particularly the AI profile if you are subject to AI-specific regulation.
Do not attempt to flip the switch in one quarter. The compatibility surface is too large and the tooling ecosystem upgrades on different schedules. A six-month migration with parallel running is the realistic timeline for most organizations.
How Safeguard Helps
Safeguard ingests SPDX 3.0 and 3.0.1 SBOMs natively and applies our reachability and policy analysis across both the Software and AI profiles. Griffin AI surfaces AIBOM-specific risks alongside traditional CVE risk, including training data provenance gaps, model-license incompatibilities, and unsafe dataset-flag conditions defined in the AI profile. Policy gates can enforce profile-conformance requirements, blocking deployments where the SBOM lacks the Build profile evidence needed for SLSA attestation or the AI profile content needed for AI Act compliance. TPRM scoring incorporates SBOM-quality signals from the profile model, and our zero-CVE base images ship as SPDX 3.0.1 documents with full profile coverage.