AI SBOMs: When Component Visibility Has to Include Models, Data, and Infrastructure
In May 2026, CISA and G7 partners released voluntary guidance on Software Bill of Materials for AI - Minimum Elements. The guidance is intended to improve transparency in artificial intelligence systems and their supply chains.
CISA frames an SBOM as an "ingredients list" that helps organizations understand supply chains and make risk-informed decisions. For AI systems, that ingredients list needs to include more than ordinary software packages.
The guidance describes AI-specific SBOM information across areas such as metadata, system-level properties, models, datasets, infrastructure, security properties, and key performance indicators.
For this handbook, the important point is not that AI SBOMs are a new proof of assurance. They are transparency artifacts. They become useful when they are scoped to a product, version, model, dataset, service, or lifecycle decision, and when the recipient can understand their source, freshness, limitations, and verification path.
The useful assurance question is not "Do we have an AI SBOM?" It is "Can this artifact support a decision about an AI-enabled product or service?"
Software Bill of Materials for AI - Minimum Elements — CISA and G7 partners, 12 May 2026
Choose one AI-enabled product, service, or feature and define the minimum evidence package needed for acceptance or continued use. Include software components, model identity, datasets, infrastructure dependencies, excluded items, refresh triggers, and verification limits.
Who should read this
| Role | Why it matters |
|---|---|
| Product-security leads | To understand how AI components, datasets, models, and infrastructure affect product assurance. |
| Procurement and supplier-assurance teams | To ask better questions about AI-enabled products and services. |
| Suppliers and manufacturers | To prepare evidence-backed answers about AI system composition and limitations. |
| Implementers | To understand where transparency artifacts may need repository, exchange, and verification workflows. |
Why ordinary SBOM thinking is not enough for AI systems
Traditional SBOM thinking often starts with software components: package names, versions, licenses, suppliers, and dependency relationships. AI systems can include those things, but they can also depend on:
- model identity, version, properties, and provenance;
- training, evaluation, or operational datasets;
- infrastructure and runtime services;
- model weights and external references;
- security properties and known vulnerabilities;
- performance indicators and evaluation context.
That means the assurance question changes. Buyers and reviewers need to know not only "what packages are in this product?" but also "which model, data, infrastructure, and service dependencies affect this decision?"
For example, an AI gateway used to triage support tickets might include ordinary application dependencies, a hosted large-language-model service, prompt templates, retrieval indexes, evaluation datasets, cloud inference infrastructure, monitoring services, and policy rules that shape outputs. A useful AI SBOM would not turn that into a single magic assurance artifact. It would identify what changed, what is excluded, which version or service is being relied on, and how the buyer can verify freshness before acceptance or renewal.
SBOM, VEX, and Component Visibility explains how SBOM, VEX, and related artifacts fit into assurance decisions.
What AI SBOMs can help show
AI SBOMs can help make hidden dependencies visible. They may support:
| AI SBOM area | Evidence value |
|---|---|
| Metadata | Shows who produced the artifact, when, in what format, and for what system. |
| System-level properties | Describes the AI system, components, data flows, usage, and intended application area. |
| Models | Identifies models, versions, producers, properties, hashes, licenses, and external references. |
| Dataset properties | Records dataset identity, provenance, lifecycle use, licensing, and relevant properties. |
| Infrastructure | Identifies physical, virtual, hardware, cloud, or runtime dependencies. |
| Security properties | Captures security measures, vulnerabilities, threat models, or access-control assumptions. |
| Key performance indicators | Records evaluation or operational metrics needed to understand model behavior in context. |
That visibility helps procurement, product-security, and assurance teams ask more specific questions about AI-enabled products and services.
The Evidence Maturity Model is useful when deciding whether an AI SBOM is only an assertion, a produced artifact, or something verifiable and retained.
What AI SBOMs still do not prove
An AI SBOM does not prove that an AI system is safe, fair, secure, robust, lawful, or appropriate for a given use.
It also does not prove by itself that:
- the model behaves acceptably in the buyer's environment;
- the datasets are appropriate, complete, representative, or lawfully usable;
- the system is free from vulnerabilities or adversarial weaknesses;
- the listed infrastructure is configured securely;
- the artifact is current, complete, or independently verified.
Like any transparency artifact, an AI SBOM becomes stronger when it is tied to a decision, scope, source, verification path, known limitations, and retention plan.
Use the Evidence Checklist to review scope, source, freshness, limitations, verification, and retention.
Procurement questions for AI-enabled products
For AI-enabled products and services, supplier questions should become more precise:
- Which AI models, datasets, services, and infrastructure components are in scope?
- Which versions, hashes, producers, licenses, and external references apply?
- What is excluded from the AI SBOM, and why?
- How often is the AI SBOM refreshed after model, data, infrastructure, or service changes?
- What security properties, known vulnerabilities, and limitations are recorded?
- Who retains the artifact, and how can a buyer verify freshness and scope?
A weak answer says: "We can provide an AI SBOM."
A stronger answer provides a product-scoped AI SBOM with model, dataset, infrastructure, and software-component scope; names exclusions and limitations; records producer, timestamp, format, repository location, and refresh triggers; and explains how the buyer can verify freshness before acceptance, renewal, or major change.
Supplier Security Questions can be adapted for model, dataset, infrastructure, and service evidence.
How to treat AI SBOMs as evidence
Treat an AI SBOM as one artifact inside an evidence package, not as assurance by itself.
A useful AI SBOM should support a decision such as supplier onboarding, product acceptance, update approval, vulnerability response, audit, or continued use. It should be clear about:
- product, service, model, dataset, infrastructure, and lifecycle scope;
- producer, source, timestamp, format, and repository location;
- verification method and known limitations;
- refresh triggers after model, data, service, infrastructure, or source changes;
- retention owner and review cadence.
Recommended reading:
- Standards to Evidence and Technology Mapping Workflow for mapping artifact roles and confidence.
- Component Provenance Example for a worked example of moving from a component list to usable assurance evidence.
- Evidence Repositories, Logs, and Retention for keeping transparency evidence usable after acceptance, update, repair, transfer, or audit.