When a federal contractor asked Sonatype's own field team in early 2025 how to produce an AI Bill of Materials for a fine-tuned LLM pipeline, the honest answer was: bolt an SBOM tool onto it and hope the model weights, training data lineage, and prompt templates get captured somewhere in the process. That gap is the story of AIBOMs right now. The U.S. Commerce Department's NTIA flagged "AI transparency mechanisms" as a priority as far back as 2023, CISA and NIST have both published draft guidance referencing AI component inventories in 2024-2025, and enterprises deploying models from Hugging Face, OpenAI, or fine-tuned open-weight checkpoints have no standard way to answer "what's actually in this model, and where did it come from?" This glossary post explains what an AI Bill of Materials is, why traditional SBOM tooling like Sonatype's falls short, and how Safeguard treats AIBOMs as a first-class artifact rather than an SBOM afterthought.
What Is an AI Bill of Materials (AIBOM)?
An AI Bill of Materials is a structured inventory of everything that goes into an AI system: the base model architecture, training and fine-tuning datasets, model weights and versions, third-party libraries (PyTorch, TensorFlow, transformers), prompt templates, embeddings, and any adapters like LoRA layers. CycloneDX 1.6, released by OWASP in April 2024, was the first major SBOM standard to add native "ML-BOM" fields for model provenance, quantization details, and dataset hashes. Unlike a traditional SBOM, which stops at package names and version numbers, an AIBOM has to answer questions a CVE scanner never asks: was this model trained on data with a commercial-use license, has the checkpoint been fine-tuned since its last security review, and does it depend on a base model like Llama 3 or Mistral 7B that has its own disclosed vulnerabilities. As of mid-2025, fewer than 15% of organizations deploying production AI systems maintain any formal AIBOM, according to a Linux Foundation survey of over 400 enterprises.
Why Doesn't Sonatype's SBOM Approach Cover AI Components Well?
Sonatype's Nexus and Lifecycle platforms were built around package-manager ecosystems — npm, Maven, PyPI, NuGet — where a component is a discrete, versioned artifact with a clear registry and a CVE feed behind it. That model breaks down for AI systems in three concrete ways. First, model weights aren't packages: a 7-billion-parameter checkpoint downloaded from Hugging Face has no CVE database, no semantic version tied to a vulnerability disclosure process, and no package registry enforcing integrity. Second, dataset provenance is invisible to dependency scanners; Sonatype can tell you that a repo imports transformers==4.38.2, but it cannot tell you whether the model loaded through that library was trained on scraped data that later triggered a takedown notice, the way several Stable Diffusion derivatives did in 2023. Third, fine-tuning creates derivative artifacts that never touch a package manager at all — a company that fine-tunes GPT-4 or Llama 3 internally produces a new model asset with no SBOM trail, because nothing about that process resembles npm install. Sonatype has added some AI-related CVE coverage to its vulnerability database, but coverage of model-level risks like data poisoning, prompt injection surface, or weight tampering remains thin compared to its 20+ years of depth in open-source package scanning.
What Regulatory Pressure Is Driving AIBOM Adoption in 2025?
The clearest driver is the EU AI Act, which entered into force on August 1, 2024, with high-risk AI system obligations — including documentation of training data and model components — phasing in through August 2026. In the U.S., the October 2023 Executive Order on AI (14110) directed NIST to develop guidelines for AI system documentation, and NIST's AI Risk Management Framework Generative AI Profile, published in July 2024, explicitly recommends component-level inventories for foundation models used in regulated environments. Federal agencies working under OMB Memo M-24-10 (March 2024) now have to inventory AI use cases and their underlying components, mirroring the SBOM mandate that Executive Order 14028 created for software back in May 2021. For any company selling into government or financial services, this is the same pattern that made SBOMs mandatory reading in 2021-2022 — except the artifact under scrutiny is now a model, not a JAR file.
How Is an AIBOM Different From a Model Card?
A model card documents intended use, performance metrics, and known limitations for humans reading documentation; an AIBOM is a machine-readable inventory built for automated security and compliance tooling. Hugging Face popularized model cards starting in 2019, and they're genuinely useful for understanding a model's training objective or benchmark scores — but a model card is prose, not structured data, and it has no obligation to list every training dependency, license, or upstream component hash. An AIBOM, by contrast, is meant to be ingested by a scanner the same way a CycloneDX or SPDX SBOM is ingested by Dependency-Track: it needs machine-parseable fields for dataset identifiers, base model hashes, and library versions so that when a CVE drops against a specific transformers version or a data-poisoning disclosure hits a public dataset, an automated pipeline can flag every AI system that touches it. Treating a model card as a substitute for an AIBOM is one of the more common gaps teams find when they're audited against the EU AI Act's Article 11 technical documentation requirements.
What Should a Complete AIBOM Actually Contain?
A complete AIBOM needs six categories of data: base model identity and version hash, training and fine-tuning dataset sources with licensing terms, the full software dependency tree (frameworks, tokenizers, serving infrastructure), model configuration and hyperparameters relevant to security posture (quantization, context window, safety fine-tuning status), third-party API dependencies for systems that call out to hosted models like Claude or GPT-4, and a cryptographic hash or signature for the deployed artifact so tampering is detectable. CycloneDX's ML-BOM extension, formalized in the 1.6 spec, covers most of these fields, but adoption is still early — most organizations that generate CycloneDX SBOMs for their application code today are not extending that same pipeline to cover the models their applications call. A 2025 OpenSSF working group survey found that while over 60% of enterprises generate SBOMs for traditional software, fewer than 20% have extended that practice to any AI or ML component, leaving a documented but largely unfilled compliance gap.
How Do Teams Actually Generate an AIBOM Today?
Most teams generate an AIBOM by combining three separate processes that don't yet talk to each other: a traditional SBOM tool for the application's software dependencies, manual documentation pulled from Hugging Face model cards or internal training logs for the model itself, and a spreadsheet or wiki page tracking dataset licensing that someone updates inconsistently. CycloneDX's cyclonedx-python and cyclonedx-bom tooling added experimental ML-BOM component types in late 2024, letting teams tag a model as a machine-learning-model component type with fields for modelCard metadata, but very few CI/CD pipelines call this automatically the way they call npm audit or a container scan. The practical result, as of 2025, is that most AIBOMs that exist at all were built once for a specific audit — an EU AI Act conformity assessment or a federal procurement questionnaire — rather than generated continuously as models get retrained or swapped.
How Safeguard Helps
Safeguard treats AI components as first-class citizens in the software supply chain, not an add-on bolted to an existing SBOM workflow. That means Safeguard's platform inventories base models, fine-tuned checkpoints, training and evaluation datasets, and the full library dependency chain in the same continuous pipeline that tracks your application's open-source components — so an AIBOM isn't a one-time audit deliverable, it's generated and refreshed every time a model or dependency changes. When a new CVE lands against a library like transformers or torch, or a licensing dispute surfaces against a public dataset, Safeguard maps that disclosure directly to every model and service that depends on it, the same way it maps a CVE to every container image built from a vulnerable base layer. For teams facing EU AI Act Article 11 documentation requirements or federal AI inventory mandates under OMB M-24-10, Safeguard produces machine-readable, CycloneDX-compatible AIBOM output alongside standard SBOMs, so compliance teams aren't maintaining two disconnected systems of record. And because Safeguard was built around continuous software supply chain monitoring rather than retrofitted from a package-registry-era SBOM tool, it closes exactly the gap described above: model weights, dataset provenance, and fine-tuning lineage get tracked with the same rigor as a package.json — before an auditor, a regulator, or an attacker finds the gap first.