AI bills of materials have crossed the threshold from research artifact to procurement requirement in 2026. Several federal contracting flows now require an AIBOM as part of the technical submission for any system involving machine learning, and the EU AI Act's high-risk system documentation expects equivalent content. The two specifications competing for adoption are CycloneDX's ML-BOM extension and the SPDX 3.0 AI profile, and the choice between them is non-trivial. This post compares them on the dimensions that actually matter for production use.
The framing assumes you are picking a spec to standardize on, either for emitting your own AIBOMs or for ingesting them from suppliers. We will skip the history of how each spec evolved and focus on what they encode, what they omit, and how the tooling ecosystems compare today.
What does CycloneDX ML-BOM actually cover?
CycloneDX ML-BOM is an extension to the CycloneDX 1.6 specification that adds first-class component types for models, datasets, and training environments. A ML-BOM component for a model captures the model name, version, format, parameter count, license, training context, and a hash of the weight artifact. Dataset components capture provenance, licensing, content classification, and bias documentation. The spec leans heavily on the existing CycloneDX vocabulary for dependencies, which means an ML-BOM looks like a normal software BOM with new component types layered in. This is a substantial advantage in practice because existing CycloneDX tooling, signature verification, and ingestion pipelines work without modification. The Anchore syft tooling, the Snyk and JFrog scanners, and the major SBOM ingestion platforms all handle ML-BOM components today, with the OWASP-curated examples providing a useful reference for what a complete document looks like.
How does SPDX 3.0 handle AI components?
SPDX 3.0 introduces an AI profile alongside profiles for security, build, and licensing, and the design philosophy is different from CycloneDX. SPDX treats AI as one facet of a richer document model, with explicit relationships between components, builds, and AI-specific metadata. The AI profile defines model and dataset elements with fields covering training environment, energy consumption, performance metrics, safety risk classification, and intended use. The richness is higher than ML-BOM, particularly for governance-related metadata, and the relationship model is more expressive. The trade-off is tooling maturity. SPDX 3.0 was finalized in late 2024 and the AI profile in mid-2025, and the ecosystem of producers and consumers is still catching up. Reference implementations exist, but the integration depth in mainstream security tooling lags CycloneDX by roughly a year. For teams optimizing for breadth of tooling, this matters; for teams optimizing for governance completeness, SPDX 3.0 may be the better choice.
Where do the specs converge and diverge?
The two specs converge on the basic content set, which is reassuring for the ecosystem. Both cover model identity, training data references, license information, and component hashes. Both support hierarchical composition where a model card references its constituent training datasets. Both integrate with the broader BOM tooling around signing, distribution, and ingestion. The divergence is in scope and emphasis. CycloneDX ML-BOM emphasizes the supply chain question: what components went into this AI system, and can I track them across versions. SPDX 3.0 emphasizes the governance question: what does this AI system do, how was it built, what risks does it carry. A team that needs both is increasingly emitting both, which the tooling supports through cross-format conversion, though the round-trip is lossy for the spec-specific fields. The pragmatic recommendation we give clients in 2026 is to standardize on ML-BOM for operational supply chain use and to emit SPDX 3.0 alongside it where governance reporting demands it.
What about model card and data card integration?
Model cards and data cards predate both BOM specs and have their own evolutionary history through the Google and Hugging Face ecosystems. The good news is that both ML-BOM and SPDX 3.0 explicitly support model card content as embedded or referenced metadata, and the major model hubs are now emitting both card formats and BOM formats from the same source-of-truth metadata. Hugging Face's model card schema can be mechanically converted to ML-BOM component content, and the conversion tooling has matured to the point where most major model publishers ship both. The remaining friction is at the dataset layer, where dataset cards are far less standardized than model cards and the provenance metadata is often missing from public datasets entirely. This is a real gap and a reason why dataset-level AIBOM content remains the weakest part of most real-world documents.
What should procurement actually require?
Procurement requirements in 2026 are converging on a baseline that should be table stakes for any AI system entering an enterprise environment. The baseline includes a complete ML-BOM or SPDX 3.0 AI profile document for the deployed system, covering all models, all training datasets referenced by those models, all major framework dependencies, and the runtime serving stack. The document should be cryptographically signed by the supplier, with the signing key verifiable through a known public infrastructure such as Sigstore. The document should include vulnerability and risk findings against the components, either as embedded VEX statements or as a parallel VEX document. And the document should be machine-ingestible into the buyer's existing supply chain tooling without manual transformation. Suppliers who cannot meet this baseline are increasingly being filtered at the procurement stage, particularly in regulated sectors. The bar will only continue to rise.
How Safeguard Helps
Safeguard ingests both CycloneDX ML-BOM and SPDX 3.0 AI profile documents through a unified pipeline, normalizing them into a common internal model for cross-supplier comparison. Griffin AI runs reachability analysis on the components declared in supplier ML-BOMs, surfacing which CVEs in the supplier's model-serving stack actually matter for the way you intend to deploy. Policy gates block ingestion of artifacts that lack signed AIBOM documents or that include model components from non-allowlisted publishers. TPRM scoring evaluates suppliers on AIBOM completeness, signing discipline, and historical disclosure quality, so procurement teams have a defensible scoring rubric. The result is that the AIBOM becomes an operational artifact rather than a compliance checkbox.