In April 2024, the SPDX project shipped version 3.0 — the first ground-up rewrite of the specification since SPDX 2.0 landed in 2015. The change isn't cosmetic. SPDX 3.0 restructures the entire data model around linked "profiles," and for the first time gives security and compliance teams a standardized vocabulary for describing AI and machine learning components inside a software bill of materials. That matters because by 2024 most enterprise applications shipped with at least one embedded model, yet SBOMs still treated a fine-tuned classifier the same way they treated a Log4j jar: an opaque package with a name and a version number, nothing about training data, risk tier, or energy footprint. SPDX 3.0's new AI profile changes that. This post breaks down what actually shipped, how it holds up against CycloneDX — the format Sonatype has bet on — and what "spdx 3.0 ai bom" support means for teams that need to produce both traditional SBOMs and AI BOMs on the same deadline.
What Actually Changed in SPDX 3.0, and Why Did It Take Nine Years?
SPDX 3.0 replaced a flat, package-centric data model with a graph of typed objects organized into eight profiles — Core, Software, Build, AI, Dataset, Lite, Security, and Licensing — and it took nine years because the working group had to solve a harder problem than "add more fields": making one document format serve build engineers, license reviewers, vulnerability analysts, and now ML teams without forcing any of them to parse fields they don't need.
SPDX 2.0 (2015) modeled everything as a "Package" or "File" connected by a short list of relationship types, which was enough for source-and-binary SBOMs but had no schema for how a model was trained or what data touched it. SPDX 2.2.1 became the basis for ISO/IEC 5962:2021, and 2.3 (April 2023) bolted on incremental license fields, but the object model itself never changed. SPDX 3.0 is a genuine rewrite: it's serializable as JSON-LD, RDF/Turtle, or the older tag-value and spreadsheet formats, and every element now carries a globally unique IRI so that a Build profile document and an AI profile document can reference the same artifact without duplicating metadata. The SPDX community submitted 3.0 to ISO for the same treatment 2.1 received, a process still moving through committee as of 2025.
What Is an AI BOM, and How Does SPDX 3.0's AI Profile Define One?
An AI BOM is a structured inventory of the models, datasets, and training-pipeline metadata that make up an AI system, and SPDX 3.0 formalizes one through its dedicated AI profile, which introduces an AIPackage object carrying more than 20 purpose-built properties — domain, informationAboutTraining, informationAboutApplication, energyConsumption, hyperparameter, modelExplainability, standardCompliance, safetyRiskAssessment, typeOfModel, and autonomyType among them.
Concretely: a bank deploying a fraud-detection model previously listed "scikit-learn 1.3.0" and "xgboost 1.7.6" as dependencies and called it done. Under SPDX 3.0, that same deployment records safetyRiskAssessment (mapped to a risk tier), typeOfModel ("gradient-boosted tree"), useSensitiveInformation (true/false), and a trainedOn relationship pointing to one or more DatasetPackage elements. The companion Dataset profile captures how that training data was collected, whether it was anonymized, and its confidentialityLevel — the fields an auditor actually asks for when a model touches PII. This is the first time an SBOM standard has tried to answer "what data trained this model and how risky is it" rather than just "what libraries does it import."
How Does SPDX 3.0 Compare to Sonatype's CycloneDX for AI and ML Components?
Sonatype's tooling — Nexus Lifecycle, Nexus Repository, and its component intelligence feeds — has historically prioritized CycloneDX, the OWASP-governed format, over SPDX, and while CycloneDX added its own machine-learning extension (ML-BOM) in version 1.5 in mid-2023 and expanded it again in 1.6 in April 2024, the two specs diverge in philosophy: CycloneDX bolts AI/ML metadata onto its existing component schema as a modelCard sub-object with roughly a dozen fields (modelParameters, quantitativeAnalysis, considerations, datasets), while SPDX 3.0 treats AI as a first-class linked-data profile with its own object types and relationship graph connecting models, datasets, and the builds that produced them.
The practical consequence for buyers is format fragmentation at exactly the moment regulators want less of it. Sonatype's platform generates CycloneDX by default and exports SPDX as a secondary option, which means teams standardized on Sonatype often produce ML-BOM data that downstream SPDX-only consumers — including some federal intake pipelines aligned to Executive Order 14028's SBOM mandate from May 2021 — can't ingest without translation. Neither format has fully won: CISA's SBOM tooling guidance still lists both as acceptable, and NTIA's original 2021 "minimum elements" document predates AI BOMs entirely, so neither the government baseline nor either vendor ecosystem has forced convergence yet.
Why Are Regulations Making AI BOMs Urgent in 2025 and 2026?
Binding deadlines are now on the calendar, not hypothetical: the EU AI Act entered into force on August 1, 2024, and requires providers of high-risk AI systems to maintain detailed technical documentation and post-market monitoring records starting August 2, 2026 — documentation that is nearly impossible to assemble retroactively if you weren't already tracking model provenance. Colorado's AI Act, originally set to take effect February 1, 2026, adds a state-level requirement for impact assessments on "high-risk" automated decision systems, which again depends on knowing exactly which models are deployed where.
On the US federal side, NIST's AI Risk Management Framework (published January 2023) and NTIA's follow-on reporting on AI transparency have pushed agencies to pilot AI-component attestation questionnaires layered on top of the SBOM requirements OMB memo M-22-18 (September 2022) already imposed on software vendors. The pattern is consistent across all of these: an organization that can already generate a compliant SBOM has maybe half the data it needs for an AI BOM. The other half — training data lineage, risk classification, explainability notes — is exactly what SPDX 3.0's AI and Dataset profiles were built to capture, which is why "spdx 3.0 ai bom" has become a live search term for compliance teams rather than a spec footnote.
What Are the Practical Challenges in Generating SPDX 3.0 AI BOMs Today?
Tooling maturity is the biggest gap: as of 2025 only a handful of open-source generators — the spdx-tools Python library's 3.0 support, which reached usable beta status in late 2024, chief among them — can emit valid SPDX 3.0 AI profile documents, and mainstream ML platforms like Hugging Face, MLflow, and most enterprise model registries still have no native "export AI BOM" button.
That leaves teams hand-mapping existing model cards to SPDX fields, which introduces three recurring problems. First, model card standards (Hugging Face's card format, Google's 2019 Model Cards for Model Reporting) don't map one-to-one onto SPDX's AIPackage properties, so someone has to do the translation manually or write a custom exporter. Second, training-data provenance is frequently unknown for models fine-tuned on top of open-weight foundation models — a team fine-tuning Llama or Mistral checkpoints often can't fully populate informationAboutTraining for the base model's original training run, leaving gaps in the graph. Third, models in active MLOps pipelines can retrain daily or weekly, which breaks the assumption — inherited from source-code SBOMs — that a BOM corresponds to a single, stable release; SPDX 3.0's versioning fields help, but most CI/CD pipelines aren't yet wired to regenerate an AI BOM on every retrain the way they regenerate a source SBOM on every build.
How Safeguard Helps
Safeguard treats SPDX 3.0 and CycloneDX as first-class, interchangeable inputs rather than picking a side the way single-format tooling does, so teams that inherited CycloneDX ML-BOM data from Sonatype-based scanning and teams standardizing on SPDX 3.0 both land in the same normalized inventory instead of two disconnected spreadsheets. Our pipeline ingests model registries, CI/CD build metadata, and dataset catalogs to auto-populate the AI profile fields — typeOfModel, safetyRiskAssessment, informationAboutTraining, dataset lineage — that most teams are currently filling in by hand, and flags gaps (an unmapped base model, a missing confidentiality level) before an auditor finds them first.
On top of that inventory, Safeguard correlates AI and traditional software components against the same vulnerability and license intelligence, so a risky dependency inside a training pipeline shows up with the same severity scoring as a vulnerable library in production code. For teams facing EU AI Act technical-documentation deadlines in 2026 or EO 14028 self-attestation requirements today, Safeguard generates the underlying SPDX 3.0 and CycloneDX artifacts on demand, keeps them versioned alongside every model retrain, and exposes a single compliance dashboard that doesn't care which format your last scanner happened to emit. If your current AI BOM process is a manual export from Sonatype reconciled against a spreadsheet of model cards, that's exactly the gap Safeguard is built to close.