AI Bill of Materials (AIBOM): The Missing Layer in AI Supply Chain Security

Software Bill of Materials (SBOM) infrastructure answered one question: what components are running in this application? The 2021 Biden Executive Order on Improving the Nation’s Cybersecurity made SBOM requirements a condition of federal procurement, accelerating commercial adoption.

AI systems have a parallel but deeper visibility problem. A traditional SBOM captures libraries, versions, and dependencies. An AI system adds training datasets (provenance, licensing, and potential biases), model weights, fine-tuning procedures, prompt templates, and retrieval corpora. A software SBOM for a PyTorch model tells you what Python packages are installed — nothing about what the model learned, from what data, with what known limitations.

The AI Bill of Materials (AIBOM) — sometimes written AI-BOM or ML-BOM — is the artifact that closes this gap. This post covers what an AIBOM is, the emerging standards that define it, how it overlaps with regulatory documentation requirements, and the tooling landscape for practical implementation.

What Is an AIBOM?

An AIBOM is a comprehensive, machine-readable inventory of all components associated with an AI system. The Linux Foundation's research report Implementing AI Bill of Materials (AI BOM) with SPDX 3.0 — authored by Karen Bennet, Gopi Krishnan Rajbahadur, Arthit Suriyawongkul, and Kate Stewart — defines the concept as expanding on SBOM to include documentation of algorithms, data collection methods, frameworks and libraries, licensing information, and standard compliance.

Unlike an SBOM, which has a well-defined minimum element set, AIBOM is still gaining definitional consensus. But across the major standards efforts (SPDX 3.0, CycloneDX ML-BOM, NIST AI RMF, and EU AI Act Annex IV), the core content requirements are converging around six categories:

1. Model specifications: Architecture, version, configuration, provenance, training framework
2. Training data sources: Dataset origins, licenses, quality assessments, preprocessing steps, known biases or gaps
3. Application-to-model mapping: Which applications depend on which models, and with what criticality
4. Model card metadata: Intended use, known limitations, performance benchmarks, ethical considerations, out-of-scope uses
5. Dependencies and tools: Libraries, inference frameworks, compute environments, MLOps tooling
6. Compliance and safety information: Regulatory mappings, fairness testing results, safety evaluations, red-team findings

The primary purpose of this inventory is supply chain transparency: enabling organizations, regulators, and downstream users to understand the provenance and risk profile of AI components — much as a drug manufacturer documents active ingredients and their sources.

The Standards Landscape

CycloneDX: ML-BOM from v1.5 Onward

The most widely deployed SBOM standard, OWASP CycloneDX — now an Ecma International standard (ECMA-424) — began incorporating machine learning transparency in version 1.5, released June 2023. CycloneDX v1.5 introduced ML-BOM as a first-class component type, allowing organizations to define ML models as components with associated metadata including:

• Training data description and categorization
• Model type and architecture
• Deployment method and environment
• Dependency relationships with other components and services

CycloneDX v1.6 (released 2024) added environmental data — energy usage and carbon emissions from training and inference — plus CycloneDX Attestations (CDXAs) for machine-readable compliance evidence. Version 1.7 added citation capabilities for verifiable provenance chains.

This multi-BOM architecture — capturing SBOM, ML-BOM, CBOM, and OBOM in a single document — makes CycloneDX the most tooling-ready AIBOM standard available. Over 200 tools support CycloneDX, including GitHub’s dependency graph and most commercial ASPM platforms.

SPDX 3.0: AI and Dataset Profiles

The other major SBOM standard — SPDX (Software Package Data Exchange), maintained by the Linux Foundation — added AI-specific capabilities in SPDX 3.0, published in 2024. SPDX 3.0 introduced two new profiles directly relevant to AIBOM:

The AI Profile standardizes how to document AI systems and their components. Key properties include:

• AI/domain: The application area in which the system operates (e.g., healthcare, finance, autonomous systems)
• AI/informationAboutTraining: Training data sources, preprocessing techniques, training algorithms
• AI/modelExplainability: How well the system's decisions can be understood and interpreted
• AI/safetyRiskAssessment: Evaluation of safety risks integrated across the AI lifecycle
• AI/modelDataPreprocessing: Data preparation steps that affect model behavior

The Dataset Profile documents training and evaluation datasets, including data collection methodology, known biases, licensing, and quality metrics.

SPDX 3.0 uses JSON-LD serialization enabling formal relationship expressions like “trained on” or “evaluated against” specific datasets. The Linux Foundation’s April 2025 report Implementing AI Bill of Materials (AI BOM) with SPDX 3.0 (DOI: 10.70828/RNED4427) provides JSON-LD examples and schema validation guidance.

NTIA SBOM Guidance and AI Adaptation

The National Telecommunications and Information Administration (NTIA) established the foundational SBOM minimum elements framework that underpins U.S. federal procurement requirements. While NTIA's guidance is software-focused, CISA's 2024 document Framing Software Component Transparency explicitly recognizes SBOM adaptation for AI systems as an emerging frontier, noting the need for validation mechanisms and integration with vulnerability intelligence.

CISA's 2025 draft updates to SBOM minimum elements add richer metadata requirements for proactive risk management and are expected to inform future guidance specifically addressing AI component transparency. Organizations building AIBOM programs should anticipate that NTIA/CISA minimum element requirements will eventually extend to AI components in federal supply chains.

Model Cards, System Cards, and Their Relationship to AIBOM

Model cards — introduced by Google researchers Mitchell et al. in 2018 and widely adopted since — are the human-readable precursor to machine-readable AIBOM. A model card documents intended use, limitations, training data characteristics, performance metrics across subgroups, and ethical considerations. System cards extend this to multi-model or deployed system contexts.

The relationship between model cards and AIBOM is complementary, not competitive. A model card is narrative documentation designed for human review; an AIBOM entry is machine-readable structured data designed for automated ingestion, tooling analysis, and regulatory reporting. In a mature AI governance program, model card content is the source of truth that is serialized into AIBOM format for supply chain and compliance tooling.

Both the EU AI Act and the NIST AI RMF encourage model card adoption as a documentation practice. The EU AI Act Annex IV specifies technical documentation requirements for high-risk AI systems — including training data descriptions, evaluation results, and risk management information — that are functionally equivalent to what a well-formed AIBOM would capture. Organizations using model cards as their primary AI documentation format can treat those cards as AIBOM source material, serialized into CycloneDX or SPDX format for compliance tooling.

Regulatory Overlap: EU AI Act Annex IV and AIBOM

The EU AI Act, which entered into force August 2024 with deployer obligations phasing in through 2027, creates the most detailed regulatory documentation mandate currently in force for high-risk AI systems. Annex IV specifies that technical documentation must include:

• General description of the AI system and its intended purpose
• Description of AI system components, including software and hardware
• Description of training methodology, training datasets (including data sources, provenance, processing steps, and representativeness)
• Description of validation and testing procedures, and results
• Performance metrics and known limitations
• Changes made to the system over its lifecycle

This list maps directly to AIBOM content. Organizations building EU AI Act compliance programs and AIBOM programs simultaneously can treat them as a unified documentation effort: the AIBOM provides the machine-readable record, and a subset of that record populates the human-readable Annex IV technical documentation.

Colorado SB24-205's impact assessment requirements also overlap: training data description, known limitations, and discrimination risk factors are required elements of impact assessments under the Colorado framework, all of which a comprehensive AIBOM would capture.

The practical implication is that organizations who invest in AIBOM infrastructure now are buying down compliance costs across multiple regulatory frameworks simultaneously, rather than building separate documentation programs for each.

Why Traditional SBOMs Are Insufficient

An SBOM for a Python-based ML service will capture PyTorch, NumPy, Hugging Face Transformers, and their transitive dependencies. It will not capture:

• The training dataset — its source, vintage, composition, or license terms
• The base model that was fine-tuned — its provenance, training configuration, and known failure modes
• The fine-tuning procedure — what data was used, what objective function, what safety alignment steps were applied
• The prompt template — which may encode significant logic and constitute a form of intellectual property and attack surface
• The retrieval corpus for RAG systems — its currency, accuracy, and potential for confidential data leakage
• The evaluation framework — what benchmarks were used, on what test sets, and what performance gaps were accepted

Each element is a distinct attack surface and compliance concern. Supply chain attacks — model poisoning through contaminated training data, backdoor injection into serialized weights, adversarial examples in retrieval corpora — exploit the components that software SBOMs leave undocumented. The Australian Cyber Security Centre explicitly recommends organizations “require and maintain an AI Bill of Materials (AIBOM) and Software Bill of Materials (SBOM) or equivalent documentation for AI and ML.”

Practical Implementation

Step 1: Build the AI Asset Inventory

Before generating AIBOMs, organizations need an inventory of AI assets — every model in production, every dataset in use, every third-party AI service. Protect AI’s Guardian platform — which has scanned over 1.5 million models on Hugging Face — addresses this at the artifact level, scanning 35+ model formats (PyTorch, TensorFlow, ONNX, GGUF, Safetensors) for deserialization attacks, backdoors, and runtime threats, producing policy-enforceable provenance records.

Step 2: Select a Standards Format

For most organizations, CycloneDX v1.6+ is the practical choice for AIBOM generation: it is the most widely supported format by existing tooling, has strong community documentation, and is already integrated into CI/CD pipelines via existing SBOM tooling. SPDX 3.0 is the technically richer standard for AI-specific semantics (particularly dataset provenance and model relationship graphs), but tooling support is earlier-stage.

Organizations in regulated industries (finance, healthcare) or those building for EU AI Act compliance should implement both SPDX 3.0 AI Profile documentation for regulatory submission and CycloneDX ML-BOM for operational security tooling.

Step 3: Automate Extraction in ML Pipelines

Manual AIBOM maintenance does not scale. Embed metadata collection into training and deployment pipelines, capturing model parameters, dataset sources, and framework versions at training time and on each model update. MLflow and Weights & Biases logging capture much of the required raw data; the gap is in structured serialization to CycloneDX or SPDX format and in formal dataset provenance documentation.

Step 4: Integrate Security Scanning

Protect AI's open-source ModelScan and commercial Guardian product provide model artifact scanning that integrates directly into CI/CD pipelines. Models from Hugging Face or other external repositories are scanned for malicious code, deserialization vulnerabilities, and backdoors before entering the organization's model registry.

Lakera's Guard addresses the runtime security surface — prompt injection, data leakage, and adversarial inputs — that AIBOM documents but cannot prevent. Together, AIBOM (the inventory and documentation layer) and runtime security tooling (the active defense layer) constitute a complete AI supply chain security posture.

Step 5: Map to Regulatory Requirements

Once AIBOM infrastructure is in place, the documentation can be mapped to specific regulatory requirements:

• EU AI Act Annex IV: Extract training data, validation results, and known limitations for technical documentation filing
• Colorado SB24-205 impact assessments: Populate the data categories, discrimination testing results, and monitoring procedures sections
• SR 11-7 model inventory: Use AIBOM metadata to maintain the comprehensive model inventory required for bank model risk management
• NIST AI RMF GOVERN and MAP functions: AIBOM documentation supports the organizational context mapping that the NIST AI RMF requires

The Tooling Landscape in 2026

The AIBOM tooling market is early but accelerating:

Model artifact scanning and inventory: Protect AI Guardian leads for enterprise model scanning and supply chain security. HiddenLayer's AISec Platform provides AI detection and response, including AIBOM-based supply chain transparency for licensing checks and regulatory compliance.

Runtime security: Lakera Guard provides prompt injection detection, data leakage prevention, and content safety for LLM applications, protecting the runtime surface that AIBOM documents.

AI governance platforms including Credo AI and Holistic AI integrate model documentation into governance workflows, enabling the model card content that serves as AIBOM source material to feed directly into compliance reporting.

Open-source tooling: OWASP's CycloneDX ecosystem provides 200+ tools supporting BOM generation, management, and analysis. The aibommaker project on GitHub and SPDX's reference implementations provide starting points for organizations building custom AIBOM generation into existing ML pipelines.

The emerging pattern is a layered AIBOM stack: automated generation at pipeline integration points (MLOps tools), security scanning at model registry entry points (Guardian, ModelScan), governance and compliance mapping at the platform layer (Credo AI, Holistic AI), and runtime protection at inference (Lakera, Prompt Security).

Key Takeaways

• An AIBOM extends SBOM to capture the components software SBOMs miss: training datasets, model weights, fine-tuning procedures, prompt templates, and evaluation frameworks.
• CycloneDX v1.5+ introduced ML-BOM as a machine-readable standard for AI/ML transparency; v1.6 added environmental data and attestation support. SPDX 3.0's AI and Dataset Profiles provide deeper semantic structure for dataset provenance.
• AIBOM directly overlaps with regulatory documentation requirements: EU AI Act Annex IV, Colorado SB24-205 impact assessments, and SR 11-7 model inventories all require content that a comprehensive AIBOM captures.
• Model cards are the human-readable precursor to machine-readable AIBOM — they are complementary artifacts, not alternatives.
• NTIA/CISA SBOM frameworks are extending toward AI: organizations building AIBOM programs now are positioned ahead of expected federal guidance.
• Protect AI addresses model artifact security and supply chain scanning; Lakera addresses runtime LLM security; Credo AI and Holistic AI provide governance platform integration.
• The EU AI Act creates the most prescriptive current regulatory driver for AIBOM adoption — organizations subject to that regulation have a compliance mandate that justifies the investment.

Sources

1. Implementing AI Bill of Materials (AI BOM) with SPDX 3.0 (Linux Foundation Research, 2025) — https://www.linuxfoundation.org/research/ai-bom
2. Implementing AI BOM with SPDX 3.0 — Technical Report (arXiv, April 2025) — https://arxiv.org/abs/2504.16743
3. OWASP CycloneDX v1.5 Release — ML-BOM Introduction (OWASP Foundation, June 2023) — https://cyclonedx.org/news/cyclonedx-v1.5-released/
4. OWASP CycloneDX Standard Overview — https://owasp.org/www-project-cyclonedx/
5. Understanding SPDX 3.0 AI BOM Support (Becoming a Hacker / Omar Santos, 2024) — https://becomingahacker.org/understanding-the-spdx-3-0-ai-bom-support-7f3dbdd28345
6. Securing AI Systems Through Transparency: The Critical Role of AIBOM (Noma Security, 2025) — https://noma.security/blog/securing-ai-systems-through-transparency-the-critical-role-of-ai-bills-of-materials/
7. New Cybersecurity Guidance from CISA for Software Bill of Materials (CMS / CISA, 2025) — https://security.cms.gov/posts/new-cybersecurity-guidance-cisa-software-bill-materials-sbom
8. NTIA Software Bill of Materials — https://www.ntia.gov/page/software-bill-materials
9. Protect AI Guardian — Model Bill of Materials and Security Scanning — https://protectai.com/guardian
10. AI and Machine Learning Supply Chain Risks and Mitigations (Australian Cyber Security Centre, 2025) — https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/artificial-intelligence-and-machine-learning-supply-chain-risks-and-mitigations