AI Bill of Materials (AI-BOM): What It Is and How to Implement It
An AI Bill of Materials (AI-BOM) is a structured inventory of every component in an AI system: base models, fine-tuned adapters, training datasets, data preprocessing code, inference serving dependencies, and the provenance chain linking them together. It extends the Software Bill of Materials (SBOM) concept into the machine learning domain, where the supply chain includes not just code packages but model weights trained on external data you did not curate.
Without an AI-BOM, you cannot answer the most basic supply chain questions when an incident hits: Which of our production models used this dataset? Who fine-tuned that base model, and on what data? Does any model in our fleet depend on a third-party provider that is now compromised? In 2026, with AI embedded in fraud detection, code generation, customer service, and access control systems, those questions are no longer hypothetical.
Why SBOM Does Not Cover AI Systems
Traditional SBOMs capture code dependencies: open source packages, their versions, their licenses, and their known CVEs. That model breaks down for AI systems in three ways.
Training data provenance is not a code dependency. A model fine-tuned on web-scraped data carries risk that no package manifest will surface. If the source dataset is poisoned, biased, or licensed incorrectly, the SBOM gives no signal.
Model weights are binary artifacts with no code graph. A PyTorch .pt file or Hugging Face model checkpoint has no dependency tree a traditional SBOM tool can parse. The weight file IS the supply chain artifact, and its provenance must be tracked separately.
Pipelines multiply the attack surface. Training pipelines ingest raw data, apply transformations, call external APIs for labeling, and write outputs to shared artifact stores. Each stage is a potential injection point that SBOM tooling ignores.
An AI-BOM must therefore capture six artifact classes that SBOM does not: base model identity and source, dataset metadata and lineage, training pipeline code and configuration, fine-tuning records, evaluation and red-team results, and inference serving environment.
AI-BOM Component Taxonomy
A complete AI-BOM covers the following layers. Each layer has distinct risk characteristics and requires different tooling to capture.
Base Model Record
Model name, version, architecture, source (Hugging Face hub ID, internal registry, API provider), license, and SHA-256 hash of the weight file. This is the foundation: everything downstream inherits its risks.
Training Dataset Manifest
Dataset name, version, provenance (public corpus, proprietary, synthetic, scraped), data collection date range, known exclusions, license, and PII/sensitive data classification. Include any data augmentation or filtering steps applied.
Fine-Tuning and Adapter Records
For each fine-tuning run: base model version, dataset version used, training code commit hash, hyperparameters, compute environment, and output artifact hash. LoRA/QLoRA adapters must be tracked separately from the base model they modify.
Pipeline Dependency Graph
Traditional SBOM (packages, versions, licenses) for all training, evaluation, and serving code. Include data preprocessing scripts, labeling tools, and orchestration frameworks (Airflow, Kubeflow, MLflow).
Evaluation and Safety Results
Benchmark results, red-team findings, bias evaluation outputs, and safety classification scores. Versioned and linked to the model artifact they assessed. This creates an audit trail for regulatory and insurance purposes.
Inference Serving Environment
Container image digests, serving framework version (vLLM, TGI, ONNX Runtime), hardware type (GPU model, driver version), and any system prompts or filters applied at the serving layer that are security controls.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
AI-BOM vs SBOM: Key Differences
| Dimension | SBOM | AI-BOM |
|---|---|---|
| Primary artifact | Source code packages | Model weights + datasets |
| Format standards | SPDX, CycloneDX | CycloneDX ML extension, draft NIST format |
| Tooling maturity | High (Syft, Trivy, FOSSA) | Low (emerging: ModelScan, Protect AI) |
| CVE linkage | Direct (NVD) | Indirect (dataset vulnerabilities, model backdoors) |
| Provenance depth | Package registry | Dataset source + training lineage |
| License complexity | FOSS licenses | Dataset licenses + model use restrictions |
| Update frequency | Every dependency bump | Every training run, every fine-tune |
The CycloneDX ML extension (v1.5+) is the closest existing standard to an AI-BOM format. NIST published draft guidance on AI supply chain provenance in late 2025. Neither is yet adopted widely, which means most teams are building their own schemas in JSON or YAML today.
AI Supply Chain Attack Vectors
Understanding what you are defending against informs what to put in your AI-BOM. The MITRE ATLAS framework catalogs AI-specific adversarial techniques; the supply chain-relevant ones are:
Model poisoning via dataset contamination. Adversaries inject malicious examples into training data to cause targeted misclassification or backdoor triggers. Defense: dataset provenance tracking and anomaly detection on training label distributions.
Dependency confusion in ML pipeline packages. The same typosquatting and dependency confusion attacks that target npm and PyPI apply to packages installed in training environments. Defense: SBOM plus private registry pinning for all training dependencies.
Weight file tampering. Downloading model weights from public hubs without verifying SHA-256 hashes is equivalent to downloading binaries without signature verification. ModelScan (Protect AI) and safetensors format verification address this.
Prompt injection via training data. Malicious instructions embedded in web-scraped training data can surface as unexpected model behaviors in production. Defense: dataset filtering, red-teaming, and behavioral monitoring at inference time.
Compromised model hub accounts. If a Hugging Face account hosting a model you use is compromised, the weight file can be replaced. Pinning to specific commit hashes rather than floating version tags is the mitigation.
Implementing AI-BOM in Your Organization
Most organizations start with inventory before tooling. You cannot govern what you cannot enumerate.
Step 1: Discover All AI Systems in Production
Run a discovery sprint across cloud accounts, internal registries, and SaaS tools. Ask each engineering team to declare models in use, including third-party API calls to OpenAI, Anthropic, Google, or Cohere. Shadow AI usage is the biggest gap: a Jira-integrated AI assistant or GitHub Copilot counts.
Step 2: Define Your AI-BOM Schema
Adopt CycloneDX v1.5 ML extension as your base format. Add internal fields for business context: data classification level of training data, regulatory scope (GDPR, HIPAA, EU AI Act risk tier), and approving stakeholder. Store in your existing artifact registry (JFrog Artifactory, AWS CodeArtifact) alongside the model weights.
Step 3: Instrument Training Pipelines
Add BOM generation to your ML pipeline DAGs. MLflow supports custom artifact logging; DVC supports dataset tracking; both can emit the provenance metadata your AI-BOM schema requires. Each training run should auto-generate a BOM and link it to the resulting model artifact hash.
Step 4: Integrate with Your SBOM Process
AI-BOMs are not a replacement for SBOMs: they are complementary. Your CI/CD pipeline should generate both: Syft/Trivy for code dependencies, your ML pipeline tooling for model provenance. Feed both into your vulnerability management platform (Snyk, Dependency-Track) for unified risk scoring.
Step 5: Gate Production Deployment on BOM Completeness
Add a BOM completeness check to your model deployment pipeline. A model without a complete AI-BOM, missing dataset provenance, missing weight hash, or missing evaluation results, should not reach production. Treat it like a DAST gate in a traditional CI/CD pipeline.
Step 6: Monitor for BOM Drift
AI systems change: models are retrained, datasets are updated, serving environments are patched. Your AI-BOM must reflect the current production state, not the state at initial deployment. Schedule quarterly BOM re-validation and trigger re-evaluation whenever a new base model version or dataset version is adopted.
Tooling Landscape for AI-BOM
The tooling market is nascent compared to SBOM. These are the current options:
Protect AI / ModelScan is an open source scanner that detects malicious code embedded in serialized model files (pickle, PyTorch, TensorFlow). It addresses weight tampering risk specifically.
Protect AI / Guardian is a commercial platform for AI asset inventory and policy enforcement. It integrates with Hugging Face, MLflow, and SageMaker.
Weights and Biases (W&B) Artifacts tracks dataset versions, model versions, and run lineage for teams using W&B for experiment tracking. Good provenance capture, weak on security policy enforcement.
MLflow Model Registry tracks model versions and lineage within your training pipelines. Requires custom scripting to generate BOM-format output.
DVC (Data Version Control) tracks dataset versions with Git-like semantics. Strong provenance for data lineage; no security policy layer.
Hugging Face Hub audit logging: if using Hugging Face for model hosting, enable audit logging to detect unexpected weight updates to pinned model versions.
For most organizations, the right approach in 2026 is: DVC for dataset provenance, MLflow for training lineage, ModelScan in CI, and a custom JSON schema stitching them together into your AI-BOM format.
Regulatory Drivers: EU AI Act and Beyond
The EU AI Act (effective August 2024, compliance deadlines rolling through 2027) mandates technical documentation requirements for high-risk AI systems that functionally require an AI-BOM. Article 11 requires training, validation, and testing data specifications; data governance practices; human oversight measures; and accuracy and robustness metrics.
US Executive Order 14110 on AI safety (October 2023) directed NIST to develop AI safety standards and called for BOM-like transparency for AI models used in critical infrastructure. CISA's 2025 AI security guidance echoes this for critical sector operators.
EU AI Act high-risk categories include AI in critical infrastructure, employment decisions, credit scoring, biometric identification, and law enforcement: sectors where most enterprise security teams operate. If your organization uses AI in these contexts, AI-BOM documentation is becoming a compliance requirement, not just a best practice.
The bottom line
An AI-BOM is not a bureaucratic artifact: it is the foundation for any meaningful AI security posture. You cannot patch what you cannot inventory, and you cannot govern what you cannot trace. Start with discovery (enumerate all AI systems and third-party model dependencies), adopt CycloneDX ML extension as your schema, instrument training pipelines to auto-generate provenance records, and gate production deployment on BOM completeness. The tooling is immature but the risk is not. Organizations that build AI-BOM capability now will be positioned to meet EU AI Act requirements, respond to AI supply chain incidents, and explain their AI systems to auditors and insurers who are increasingly asking.
Frequently asked questions
What is the difference between an AI-BOM and a traditional SBOM?
An SBOM inventories software code dependencies: packages, versions, licenses, and CVEs. An AI-BOM extends this to cover AI-specific artifacts that have no code graph: model weights, training datasets, fine-tuning runs, and evaluation results. A production AI system needs both: an SBOM for its serving infrastructure and dependencies, and an AI-BOM for the model itself. CycloneDX v1.5 introduced an ML extension that covers both in a single format.
Is there a standard format for AI-BOMs?
Not yet a widely adopted one. CycloneDX v1.5 ML extension is the closest existing standard and is the recommended starting point. NIST published draft AI provenance guidance in 2025. SPDX has not yet released an ML extension. Most organizations using AI-BOMs in production today are using custom JSON schemas based on CycloneDX, with internal fields added for business context and regulatory scope.
Does the EU AI Act require an AI-BOM?
Not by that name, but Article 11 of the EU AI Act requires technical documentation for high-risk AI systems that covers training and testing data specifications, data governance, and model performance metrics, all of which an AI-BOM captures. Organizations operating AI in high-risk categories (critical infrastructure, employment, credit scoring, biometrics, law enforcement) should treat AI-BOM documentation as part of their EU AI Act compliance posture.
How do we handle third-party model APIs like OpenAI or Anthropic in our AI-BOM?
Third-party API calls are external dependencies with limited provenance visibility: you cannot inspect the weights or training data. Your AI-BOM should record the API provider, model version (including model identifier used in API calls), data sent to the API (classification level), and contractual terms covering data use and retention. Treat API-based models as third-party vendor risk, similar to a SaaS dependency, and review provider security documentation and compliance certifications.
What tools can generate AI-BOMs automatically?
The tooling ecosystem is early. Protect AI's Guardian platform offers commercial AI asset inventory. For open source, combine DVC for dataset tracking, MLflow for model and run lineage, and ModelScan for weight integrity checking. A custom script can stitch these outputs into a CycloneDX ML extension format. W&B Artifacts provides provenance tracking for teams already using Weights and Biases. Expect the market to mature significantly in 2026-2027 as regulatory pressure increases.
How often should we update our AI-BOM?
Trigger-based rather than scheduled: regenerate the AI-BOM whenever a model is retrained, a fine-tuned adapter is updated, the serving environment is upgraded, or a new base model version is adopted. Additionally, run quarterly reviews to catch drift between the documented BOM and actual production state. Shadow fine-tunes and undocumented model swaps are common in fast-moving ML teams. Treat the AI-BOM like your asset inventory: accuracy requires continuous process, not one-time documentation.
Can we use our existing SBOM tooling like Syft or Trivy for AI-BOMs?
Partially. Syft and Trivy can generate SBOMs for the code dependencies in your ML infrastructure: Python packages in your training environment, container images for your serving stack. They cannot parse model weight files or capture dataset provenance. You need additional tooling (ModelScan for weight integrity, DVC or MLflow for data and training lineage) and a custom integration layer to produce a complete AI-BOM. The code SBOM is a component of the AI-BOM, not a replacement.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.