AI Bill of Materials (AI BOM)

Unlike a flat list, an AI BOM maps a hierarchical graph of dependencies. It captures transitive dependencies that are often invisible to developers.

• Base Model: The foundational architecture (e.g., Llama 3, Mistral).
• Fine-Tuning Adapters: LoRA weights or specific checkpoints.
• Software Libraries: Exact versions of PyTorch, CUDA, and Transformers.
• Training Data: Versioned dataset identifiers and preprocessing scripts.

This graph structure is critical for tracing a vulnerability found in a low-level library back to every affected production model.

Every component in an AI BOM must be linked to its cryptographic hash (e.g., SHA-256) to ensure integrity. This transforms the BOM from a simple inventory into a tamper-evident record.

• Content-Addressable Storage: Model weights and datasets are referenced by their hash, not just a mutable version tag.
• Digital Signatures: The BOM itself is signed by the model producer to establish non-repudiation.
• Sigstore Integration: Keyless signing can bind the BOM to the developer's OIDC identity, creating a verifiable chain of custody from build to deployment.

This prevents supply chain attacks where a malicious actor silently swaps a dependency.

A robust AI BOM drills into data provenance, not just code. It documents the origin, licensing, and preprocessing of every dataset used.

• Source Attribution: URLs, DOIs, or decentralized identifiers (DIDs) for each dataset.
• Consent and Licensing: Flags for copyright status, personally identifiable information (PII) presence, and usage restrictions.
• Transformation Logs: A hash chain of all cleaning, augmentation, and filtering steps applied to raw data.

This granularity is essential for complying with the EU AI Act's requirements for high-quality, transparent training data governance.

AI BOMs rely on machine-readable standards to enable automated scanning and policy enforcement across the software supply chain.

• CycloneDX: A lightweight SBOM standard that has been extended with a specific ML-BOM profile to capture model cards, datasets, and embeddings.
• SPDX 3.0: Supports complex relationships and can link an AI model to its training datasets, code, and security vulnerabilities.
• VEX Integration: The Vulnerability Exploitability eXchange (VEX) format is paired with the AI BOM to state the actual exploitability of a known CVE in the context of a specific model's usage.

These standards allow CTOs to integrate AI risk directly into existing DevSecOps pipelines.

A static BOM is a snapshot; an effective AI BOM is a living document continuously correlated against vulnerability databases.

• CVE/PURL Mapping: Components are identified by Package URLs (PURLs) to automatically match against the National Vulnerability Database (NVD).
• Model-Specific Advisories: Scanning for vulnerabilities unique to ML, such as pickle deserialization exploits or malicious safetensor files.
• Runtime Drift Detection: Comparing the deployed model's hash against the authorized BOM to detect unauthorized fine-tuning or weight tampering in production.

This dynamic aspect ensures that a model's security posture is not just known at release time, but continuously monitored.

A comprehensive AI BOM includes sustainability metrics to meet emerging ESG reporting requirements and optimize infrastructure costs.

• Compute Carbon Footprint: Estimated CO2 equivalents generated during training, often calculated using tools like CodeCarbon.
• Hardware Profile: Details on GPU/TPU types, total compute hours, and cloud region (which impacts energy mix).
• Inference Efficiency: Benchmarking data on latency and energy consumption per query for the final model.

Including this data allows enterprise architects to make informed decisions that balance model performance with environmental impact and operational expenditure.

The foundational precursor to the AI BOM. An SBOM is a nested inventory of all open-source and proprietary software components, libraries, and transitive dependencies in a codebase.

• Standard formats: SPDX, CycloneDX
• AI BOM extension: Adds model weights, training datasets, and hyperparameters to the SBOM schema
• Vulnerability management: Enables rapid identification of compromised log4j-type dependencies in ML pipelines

The immutable record of origin and chain of custody for every artifact in the AI supply chain. Provenance answers 'who did what, when, and how' during model creation.

• SLSA Framework: Supply-chain Levels for Software Artifacts defines a graduated scale of provenance integrity
• In-toto attestations: Cryptographically signed metadata linking each step of the CI/CD and training pipeline
• Critical for: Verifying that a model was trained on the claimed data without unauthorized modification

A structured transparency document that accompanies a trained ML model, detailing its intended use, evaluation results, and limitations. A human-readable complement to the machine-readable AI BOM.

• Discloses: Training data composition, fairness evaluations, and out-of-scope use cases
• Standard: Google's original Model Card Toolkit and Hugging Face's metadata convention
• Relationship: The AI BOM provides the raw component inventory; the Model Card provides the narrative context

An OWASP standard for BOM interchange designed specifically for software and now extended to ML. CycloneDX provides the JSON/XML schema to represent an AI BOM's complex graph of components.

• ML-BOM extension: Defines objects for ml-model, dataset, and training_algorithm
• Pedigree tracking: Captures the lineage of each component, including commits, diffs, and signatures
• Tooling ecosystem: Supported by dependency-track, Syft, and Grype for continuous scanning

The end-to-end tracking of data as it flows from raw ingestion through cleaning, labeling, feature engineering, and training. Data lineage is the 'nutrition label' for the dataset component of an AI BOM.

• Captures: Schema changes, join operations, and filtering logic applied at each ETL stage
• Tools: OpenLineage, Marquez, and cloud-native services like AWS Glue Data Catalog
• Governance: Proves that training data complies with licensing and consent requirements

An open-source project enabling keyless signing and verification of software artifacts using OpenID Connect (OIDC) and a public transparency log. Directly applicable to signing AI BOM components.

• Mechanism: Short-lived ephemeral keys bound to developer or workload identities, eliminating long-term key management
• Rekor transparency log: Provides an immutable, append-only record of all signatures for non-repudiation
• AI BOM use case: Sign model weights, dataset hashes, and the BOM document itself to establish end-to-end integrity