A software bill of materials tells you which code is inside a product, but it says almost nothing about the model weights, training data and prompts that decide how an AI system behaves. An AI bill of materials (AIBOM) extends the same inventory idea to those AI-specific parts. This guide compares the two: what each one lists, which standard formats carry them, when an SBOM is enough and when you need the AI extension, and how to run both without building two separate programmes. It is written for application security, supply chain and ML platform teams, and for anyone asked by a customer or regulator to "provide an AIBOM".
Key takeaways
- An AIBOM is not a separate world. It is an SBOM that also describes models, datasets and AI configuration, and both major formats (CycloneDX and SPDX) carry it in the same document model.
- The SBOM answers "what code am I running". The NTIA minimum elements cover supplier, component name, version, unique identifiers, dependency relationships, SBOM author and timestamp.
- The AIBOM answers "what model is this and what shaped it". It records model type and architecture, training and evaluation datasets, metrics, limitations, intended use and safety assessment.
- You need the AI extension when a model changes the risk. If a system downloads, fine-tunes, hosts or chains models, a code-only SBOM leaves the highest-impact component undocumented.
- Vulnerability matching works differently. SBOM components map to CVEs through package URLs and CPEs; most model and dataset risks (poisoning, licence, bias, provenance) have no CVE and need different checks.
What each one is
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. The baseline came from the NTIA report "The Minimum Elements For a Software Bill of Materials", published on 12 July 2021 under Executive Order 14028. It defines three groups: data fields, automation support (SPDX, CycloneDX and SWID tags) and practices such as frequency, depth, known unknowns, distribution, access control and accommodation of mistakes. See the SBOM Guide for the full programme view.
An AIBOM (also written AI-BOM, AI-SBOM or ML-BOM) applies the same discipline to an AI system. CycloneDX calls its version the Machine Learning Bill of Materials (ML-BOM) and describes it as model and dataset transparency for security, privacy, safety and ethical considerations. SPDX 3.0 adds an AI profile and a Dataset profile to the core software model. The SPDX project describes an AI-SBOM as a machine-readable record covering software dependencies, models, data assets, prompt templates, AI agents with the tools they can call, licences, and ethical and security attributes. The AI Supply Chain and AI-BOM Guide covers the wider AI supply chain; this page focuses on the comparison.
Side-by-side comparison
| Dimension | SBOM | AIBOM |
|---|---|---|
| Core question | Which software components and versions are in this product? | Which models, datasets and AI configuration are in this system, and where did they come from? |
| Baseline definition | NTIA minimum elements (2021) | No single government minimum set; defined by the CycloneDX ML-BOM and SPDX 3.0 AI and Dataset profiles |
| Typical components | Libraries, packages, frameworks, containers, operating system packages | Base and fine-tuned models, weights files, adapters, training and evaluation datasets, prompt templates, agent tool definitions, plus the software stack |
| Identifiers | Package URL (purl), CPE, hashes | Model name and version, repository reference, file hashes of weights, dataset identifiers |
| Main risk use | Known vulnerability (CVE) matching, licence compliance, end-of-life tracking | Provenance, poisoning and tampering checks, licence and data-use terms, intended use, limitations, safety review |
| Change trigger | New build or dependency update | New model version, fine-tune, dataset refresh, prompt or tool change, as well as code changes |
| Who produces it | Build pipeline (software composition analysis or build plugins) | ML platform and model registry, with input from data owners and model reviewers |
| Who consumes it | Vulnerability management, procurement, customers | AI governance, risk, legal and privacy, security review, customers deploying the model |
What the AI extension adds, field by field
Both formats keep the software inventory and add AI-specific objects. The table lists fields from the published specifications so you can see what "AIBOM" means in practice.
| Information | CycloneDX 1.6 | SPDX 3.0.1 |
|---|---|---|
| Model as a component | component type machine-learning-model | AIPackage class in the AI profile |
| Dataset as a component | component type data | Dataset profile |
| How the model was built | modelCard.modelParameters: approach, task, architectureFamily, modelArchitecture, datasets, inputs, outputs | typeOfModel, hyperparameter, informationAboutTraining, modelDataPreprocessing |
| Performance | modelCard.quantitativeAnalysis.performanceMetrics | metric, metricDecisionThreshold |
| Limits and intended use | modelCard.considerations: users, useCases, technicalLimitations, ethicalConsiderations, fairnessAssessments | limitation, domain, informationAboutApplication |
| Risk and safety | ethicalConsiderations with mitigation strategy | safetyRiskAssessment, useSensitivePersonalInformation, standardCompliance |
| Autonomy | Described in considerations | autonomyType |
| Energy and environment | environmentalConsiderations (energy use, CO2 cost and offset) | energyConsumption with training, fine-tuning and inference values |
CycloneDX states that a modelCard should be given for any component of type machine-learning-model and must not be used on other component types. That rule is a useful validation check in a pipeline.
When an SBOM is enough, and when you need an AIBOM
- SBOM is enough: the product calls a third-party model only through a hosted API and ships no model files. Record the API client library in the SBOM and treat the model provider as a supplier in third-party risk review.
- AIBOM needed: the product ships or downloads model weights (for example from a public model hub), runs a model on its own infrastructure, or packages an embedding model inside a container.
- AIBOM needed: you fine-tune, distil or adapt a model with your own data. The training data and its licence and personal data status now belong to the product.
- AIBOM needed: you build an agent. The prompts, tool definitions and the APIs the agent can call change behaviour as much as code does, and SPDX explicitly lists agents and their tools as AI-SBOM content.
- AIBOM asked for by customers: enterprise buyers increasingly ask for model provenance and intended-use statements during procurement. Answering from a structured document is faster than answering a questionnaire by hand.
Small organisations can start with one SBOM per release that includes model components as machine-learning-model entries with name, version, source and hash, then add model card fields for the models that matter most. Large organisations with a model registry should generate the AI sections from registry metadata so the document stays current without manual edits.
Security trade-offs
- Automation: SBOM generation is mature and runs in the build. AIBOM fields such as limitations, fairness assessment or training data description need human input, so completeness is harder to keep up.
- Vulnerability coverage: SBOM data feeds CVE matching directly. Model risks such as a poisoned or tampered model in a public repository (MITRE ATLAS AML.T0010.003 Model Repository, under AML.T0010 Supply Chain Compromise) are found through provenance and integrity checks, not CVE feeds.
- Disclosure: an AIBOM can reveal training data sources and model architecture that you regard as confidential. Decide which fields go in the customer-facing version and keep a fuller internal version, with access control as the NTIA practices describe.
- Serialisation risk: listing a weights file does not make it safe to load. Pair the AIBOM with scanning of model files and a preference for safer weight formats. See the Hugging Face Security Guide.
Where identity fits
An agent's AIBOM entry is only complete if it records which tools and APIs the agent can call, and those calls run on service accounts, API keys or OAuth tokens. Link each tool entry to the non-human identity that executes it, so a review of the AIBOM is also a review of the agent's access. The Agent Identity and Access Guide covers how to give agents their own scoped credentials.
How to run both in one programme
- Pick one format for both. Use CycloneDX 1.6 or SPDX 3.0 for software and AI, so one tool can store, validate and query everything.
- Inventory AI assets first. List every model, dataset, embedding model and agent in production, with owner and source. The MLOps Security Guide describes where these live in the pipeline.
- Add model components to existing SBOM generation. Record name, version, supplier or repository, and a SHA-256 hash of each weights file at build or deployment time.
- Generate model card fields from the registry. Populate architecture, datasets, metrics and intended use from model registry metadata; require limitations and safety review sign-off before promotion to production.
- Pilot on one high-risk system. Validate the document against the schema, check hashes against what is actually deployed, and ask the consuming team (governance or a customer) whether it answers their questions.
- Gate releases. Fail a release when a deployed model hash is missing from the AIBOM. Roll back by reverting to the last version whose hashes match its document.
- Distribute and update. Regenerate on every model or dataset change, not only on code releases, and publish the customer version through the same channel as your SBOMs. The SBOM operations guide covers storage and distribution.
Threat model, failure modes and decision criteria by option
SBOM
Threat model. The SBOM addresses known-vulnerable and compromised software components: a library with a published CVE, an abandoned package, a dependency swapped for a malicious version (ATT&CK T1195.001 Compromise Software Dependencies and Development Tools) or a tampered build (T1195.002 Compromise Software Supply Chain). Its value is speed of answer: when a new critical vulnerability is announced, the question "where do we run this component?" becomes a query rather than a project.
Failure modes. SBOMs generated once and never refreshed; documents that list direct dependencies but not transitive ones; missing identifiers, so matching against vulnerability data fails silently; and SBOMs that describe the source tree rather than what was actually built and deployed. The NTIA practices on depth and on stating known unknowns exist because an incomplete SBOM looks complete to its reader.
Controls and decision criteria. Generate at build time from the artefact, not by hand; include purl or CPE identifiers and hashes; state depth and known unknowns; store SBOMs with the release so each deployed version can be traced; and choose tooling on identifier quality and how well it feeds your vulnerability management, not on the number of formats it exports.
AIBOM
Threat model. The AIBOM addresses risks that live in the model and its inputs rather than in code: a model downloaded from a public hub that has been tampered with or poisoned (ATLAS AML.T0010.003 Model Repository), a poisoned or mislicensed dataset (AML.T0010.002 Data Repository), a fine-tune trained on personal data without a lawful basis, and an agent whose tools reach more systems than its owners realise. None of these is found by a CVE feed; they are found by checking provenance, hashes, licences and declared use against what is deployed.
Failure modes. Model card fields copied from the upstream publisher and never checked; a weights hash recorded at training but not compared at deployment; datasets described by name only, with no version, so a refresh changes behaviour without a new document; prompt templates and tool definitions left out because they live in configuration rather than the registry; and a customer-facing AIBOM that discloses more about training data than the organisation intended.
Controls and decision criteria. Generate the AI sections from the model registry; require hashes of weights and adapters and compare them at load time; version datasets and record their licence and personal data status; include agent tools and the identity each tool runs as; validate against the schema rule that a modelCard belongs only on a machine-learning-model component; and keep separate internal and external views. Choose CycloneDX or SPDX on what your existing SBOM tooling and your customers already consume.
Worked scenarios
SBOM scenario: a new critical library vulnerability. A widely used logging or parsing library receives a critical CVE. An organisation that stores a build-time CycloneDX SBOM per release queries for the affected package URL and version range and gets a list of 14 services within an hour, with owners. Two hits are false because the library is present only in a test dependency, which the dependency relationships in the SBOM make visible. The remaining services are patched in priority order, and each fix produces a new SBOM that confirms the vulnerable version is gone.
AIBOM scenario: a support assistant built on an open-weights model. A team downloads an open-weights model, fine-tunes it on past support tickets and wraps it in an agent that can look up orders and issue refunds below a set value. Its SBOM lists the Python stack and nothing else. The AIBOM adds the base model with source repository and SHA-256 hash, the fine-tuning dataset with version, retention date and a note that it contains customer personal data, the evaluation metrics, the intended use and limitations, the prompt template, and two tools with the service accounts they run as. During review, governance notices the refund tool's service account can also cancel orders, which was never intended, and the privacy team flags that the ticket dataset needs redaction before the next fine-tune. A later deployment fails its load-time hash check because someone pulled a newer upstream revision; the AIBOM made the change visible before the model reached customers.
Detection and measurement
- Coverage: percentage of production AI systems with a current AIBOM, and of releases with an SBOM.
- Hash match rate: share of deployed model files whose hash matches the AIBOM entry; anything below 100% is a drift or tampering signal.
- Freshness: median time between a model or dataset change and the updated document.
- Completeness: share of model components with datasets, limitations and intended use filled in.
- Unknown provenance: count of models whose source repository or licence is recorded as unknown (the NTIA "known unknowns" practice).
Common failure patterns
- Treating the model as a library. A model listed only as a filename gives no provenance, version or dataset context, so a swapped or poisoned file is invisible.
- Document drift. The AIBOM is written once for a launch review and never regenerated after fine-tuning or prompt changes.
- No hashes. Without file hashes, nobody can prove that the model described is the model running.
- Agents without tools. The agent is documented, but not the tools, APIs and credentials it can use, which is where most of its risk sits.
- Two disconnected programmes. Software and AI inventories in different tools and formats, so a single incident query ("where is this component?") needs two teams.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02 | Inventories of software, services and systems, including AI components |
| NIST CSF 2.0 | GV.SC-05 | Supply chain requirements in contracts, such as delivering an SBOM or AIBOM |
| NIST CSF 2.0 | ID.RA-01 | Vulnerabilities in assets identified, validated and recorded |
| NIST SP 800-53 Rev. 5 | CM-8, SR-4, SR-11 | Component inventory, provenance and component authenticity |
| MITRE ATT&CK | T1195.001, T1195.002 | Compromised dependencies and compromised software supply chain |
| MITRE ATLAS | AML.T0010, AML.T0010.002, AML.T0010.003 | AI supply chain compromise through data and model repositories |
The OWASP Top 10 for LLM Applications 2025 entry on supply chain also discusses model provenance; see the OWASP LLM Top 10 LLM03 Supply Chain Guide.
Practitioner checklist
- Decide whether each AI system ships, hosts or only calls a model, and record the answer.
- Use one format (CycloneDX 1.6 or SPDX 3.0) for software and AI inventory.
- Record every model with name, version, source repository and SHA-256 hash of its files.
- Record training and fine-tuning datasets with source, licence and personal data status.
- List agent prompts, tools and the identities those tools run as.
- Validate documents against the schema in the pipeline and block releases with missing model hashes.
- Regenerate on model, dataset and prompt changes, not just code releases.
- Keep a customer version and a fuller internal version with access control.
- Add SBOM and AIBOM delivery requirements to supplier contracts and procurement questionnaires.
Standards and references
- NTIA: The Minimum Elements For a Software Bill of Materials
- CISA: Software Bill of Materials (SBOM)
- CycloneDX: Machine Learning Bill of Materials (ML-BOM)
- CycloneDX: v1.6 JSON Reference
- SPDX: Specification 3.0.1 AI Profile
- SPDX: AI and the AI-SBOM
- MITRE ATLAS: AI Supply Chain Compromise
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: SBOM Guide · AI Supply Chain and AI-BOM Guide · Model Supply Chain Guide · AML.T0010 Supply Chain Compromise