12.3 AI Bills of Materials (AI-BOM)¶

As organizations increasingly integrate machine learning models into their products and operations, traditional SBOMs prove insufficient. A software bill of materials tells you what code libraries are in your application, but when that application includes an ML model, critical questions remain unanswered: What data was used to train this model? Which base model was it fine-tuned from? What configuration parameters affect its behavior? These questions matter for security, compliance, and operational reasons that parallel—but extend beyond—traditional software supply chain concerns.

This section introduces the AI Bill of Materials (AI-BOM) as an emerging extension of SBOM concepts to AI/ML systems, examining standards, implementation approaches, and the regulatory pressures driving adoption.

Why Traditional SBOMs Are Insufficient¶

SBOMs designed for traditional software capture libraries, packages, and dependencies—components that execute code. AI/ML systems include additional artifact types that SBOMs weren't designed to represent.

The Gap:

A traditional SBOM for a Python ML application would capture PyTorch, TensorFlow, or scikit-learn as dependencies, but would miss:

• The pre-trained model downloaded from Hugging Face
• The dataset used for fine-tuning
• The training configuration that shaped model behavior
• The relationship between base model and fine-tuned version

Security Implications of the Gap:

Without AI-specific inventory, organizations cannot answer critical questions:

• Does this model contain a backdoor? (Model poisoning assessment)
• Was training data appropriately sourced? (Data provenance)
• Is the model vulnerable to known attacks? (Vulnerability correlation)
• What licenses apply to this model? (License compliance)
• What are the model's known limitations? (Operational risk)

Book 1, Chapter 10 detailed ML-specific supply chain risks—pickle deserialization attacks, model backdoors, dataset poisoning. AI-BOM provides the visibility necessary to assess and manage these risks.

What an AI-BOM Includes¶

An AI-BOM extends traditional SBOM concepts to capture AI/ML-specific components and their relationships.

Core Component Types:

Models:

• Model architecture (transformer, CNN, etc.)
• Weights and parameters
• Version and lineage (base model, fine-tuned variants)
• Format (SafeTensors, ONNX, pickle, etc.)
• Hash for integrity verification
• Performance metrics and benchmarks

Datasets:

• Dataset identifier and version
• Source and provenance
• Composition (what data types, distributions)
• Preprocessing applied
• Known limitations and biases
• Licensing and usage restrictions

Training Pipelines:

• Training code and scripts
• Hyperparameters used
• Random seeds (for reproducibility)
• Hardware and environment
• Training duration and cost

Configurations:

• Inference parameters (temperature, top-p, etc.)
• Quantization settings
• Deployment constraints
• Safety configurations

Dependencies:

• ML frameworks (PyTorch, TensorFlow)
• Libraries (transformers, datasets)
• Traditional software dependencies

Component Relationships:

AI-BOMs must capture relationships between components:

Fine-tuned Model
    ├── DERIVED_FROM: Base Model (Llama-2-7B)
    ├── TRAINED_ON: Dataset (internal-qa-pairs-v3)
    ├── USING: Training Pipeline (qa-finetune-pipeline)
    └── DEPENDS_ON: Libraries (transformers, peft, torch)

These relationships enable lineage tracking and impact assessment.

CycloneDX ML-BOM Profile¶

CycloneDX version 1.5 (June 2023) introduced the Machine Learning BOM (ML-BOM) profile, extending the existing specification to support AI/ML components. The current version 1.7 (October 2025) includes further enhancements.

ML-BOM Component Types:

CycloneDX defines specific component types for ML:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "components": [
    {
      "bom-ref": "sentiment-classifier-v2",
      "type": "machine-learning-model",
      "name": "sentiment-classifier-v2",
      "version": "2.1.0",
      "modelCard": {
        "modelParameters": {
          "approach": {
            "type": "supervised"
          },
          "task": "sentiment-classification",
          "architectureFamily": "transformer",
          "modelArchitecture": "BERT-base-uncased",
          "datasets": [
            { "ref": "sentiment-training-data" }
          ],
          "inputs": [{ "format": "string" }],
          "outputs": [{ "format": "classification" }]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            {
              "type": "accuracy",
              "value": "94.2%",
              "slice": "English reviews"
            }
          ]
        },
        "considerations": {
          "technicalLimitations": [
            "Performance degrades on non-English text",
            "May misclassify sarcasm and irony"
          ]
        }
      }
    },
    {
      "bom-ref": "sentiment-training-data",
      "type": "data",
      "name": "sentiment-training-data",
      "version": "1.0.0",
      "data": [
        {
          "type": "dataset",
          "contents": {
            "url": "https://example.com/datasets/sentiment-v1"
          },
          "governance": {
            "custodians": ["Data Science Team"],
            "owners": ["Acme Corp"]
          }
        }
      ]
    }
  ]
}

This example follows CycloneDX 1.7 schema conventions. Note how the model component references the dataset via bom-ref, enabling lineage tracking.

Key ML-BOM Fields:

Advantages of CycloneDX ML-BOM:

• Integrates with existing CycloneDX tooling
• Supports VEX for vulnerability exploitation status
• Designed for security use cases
• Active community development

SPDX 3.0 AI Profile¶

SPDX version 3.0 (2024) introduces AI and dataset profiles as part of a major specification update.

SPDX 3.0 Structure:

SPDX 3.0 uses a modular profile system:

• Core profile: Basic SBOM elements
• Software profile: Software packages and files
• AI profile: Models and AI systems
• Dataset profile: Training and evaluation data
• Build profile: Build process information

AI Profile Elements:

{
  "type": "ai_AIPackage",
  "spdxId": "https://example.com/sentiment-classifier",
  "creationInfo": "_:creationinfo",
  "name": "sentiment-classifier",
  "releaseTime": "2024-06-15T00:00:00Z",
  "suppliedBy": "https://example.com/acme-ml-team",
  "software_downloadLocation": "https://example.com/models/sentiment-v2",
  "software_packageVersion": "2.1.0",
  "software_primaryPurpose": "application",
  "ai_typeOfModel": ["transformer-based classifier", "BERT fine-tune"],
  "ai_autonomyType": "no",
  "ai_domain": ["nlp", "sentiment-analysis"],
  "ai_informationAboutTraining": "Fine-tuned on proprietary dataset.",
  "ai_limitation": "May exhibit bias toward English idioms",
  "ai_modelDataPreprocessing": ["Tokenized using BERT tokenizer"],
  "ai_safetyRiskAssessment": "low",
  "ai_metric": [
    { "type": "DictionaryEntry", "key": "accuracy", "value": "94.2%" }
  ]
}

Key field constraints: ai_autonomyType uses PresenceType (yes/no/noAssertion), ai_safetyRiskAssessment uses SafetyRiskAssessmentType (serious/high/medium/low), and array fields like ai_typeOfModel and ai_domain support multiple values. See the SPDX AIPackage specification for complete field definitions.

Dataset Profile Elements:

{
  "type": "dataset_DatasetPackage",
  "spdxId": "https://example.com/sentiment-training-data",
  "creationInfo": "_:creationinfo",
  "name": "sentiment-training-data",
  "releaseTime": "2024-01-10T00:00:00Z",
  "software_downloadLocation": "https://example.com/datasets/sentiment-v1",
  "software_primaryPurpose": "data",
  "dataset_dataCollectionProcess": "Web scraping with manual validation",
  "dataset_dataPreprocessing": ["Removed PII", "Normalized text"],
  "dataset_knownBias": ["Overrepresents social media language"],
  "dataset_hasSensitivePersonalInformation": "no",
  "dataset_intendedUse": "Training sentiment classifiers",
  "dataset_datasetType": ["text"],
  "dataset_datasetSize": 50000
}

SPDX vs. CycloneDX for AI-BOM:

Both standards are viable; choice depends on organizational context and existing tooling.

Model Cards and AI-BOM¶

Model cards are structured documentation about ML models, originally proposed by Mitchell et al. in 2019.¹ AI-BOMs and model cards serve complementary purposes.

Relationship:

• Model cards: Human-readable documentation about model characteristics, intended use, and limitations
• AI-BOM: Machine-readable inventory of model components and dependencies

Both CycloneDX and SPDX integrate model card concepts:

• CycloneDX includes modelCard as a component field
• SPDX AI profile fields mirror model card categories

Model Card Elements in AI-BOM:

Practical Integration:

Generate model cards from AI-BOM data for human consumption; maintain AI-BOM as source of truth for automation:

AI-BOM (machine-readable)
    │
    ├──► Vulnerability scanning
    ├──► License compliance
    ├──► Dependency tracking
    │
    └──► Model Card (human-readable)
              │
              └──► Developer documentation
                   End-user transparency
                   Regulatory compliance

Model Provenance and Lineage¶

Model provenance documents where a model came from and how it was created. Model lineage tracks relationships between models across versions and fine-tuning.

Why Provenance Matters:

• Security: Verify model wasn't tampered with
• Compliance: Demonstrate model creation process
• Reproducibility: Enable recreation of model
• Attribution: Track intellectual property and licensing

Provenance Elements:

provenance:
  origin:
    source: "huggingface.co/meta-llama/Llama-2-7b-hf"
    download_date: "2024-01-15"
    checksum: "sha256:abc123..."

  training:
    start_date: "2024-01-16"
    end_date: "2024-01-18"
    environment:
      hardware: "8x A100 80GB"
      framework: "transformers 4.36.0"
    code_repository: "github.com/acme/model-training"
    code_commit: "def456..."

  lineage:
    base_model: "meta-llama/Llama-2-7b-hf"
    relationship: "fine-tuned"
    modifications:

      - "LoRA adaptation for QA"
      - "Quantized to 4-bit"

Signing and Verification:

Model provenance should be cryptographically signed:

# Sign model file (creates signature bundle)
cosign sign-blob model.safetensors --bundle model.safetensors.bundle

# Sign provenance attestation as a separate artifact
cosign sign-blob provenance.json --bundle provenance.json.bundle

# Verify model signature
cosign verify-blob model.safetensors --bundle model.safetensors.bundle \
  --certificate-identity=<signer-identity> \
  --certificate-oidc-issuer=<oidc-issuer>

Note: For models stored in OCI registries, cosign attest can attach in-toto attestations directly to the artifact.

Dataset Integrity and Provenance¶

Datasets shape model behavior as much as architecture does. Dataset documentation is essential for AI-BOM completeness.

Dataset Provenance Elements:

• Source: Where data originated
• Collection method: How data was gathered
• Preprocessing: Transformations applied
• Composition: What the data contains
• Known biases: Recognized limitations
• Licensing: Usage rights and restrictions

Documentation Challenges:

Dataset provenance is often poorly documented:

• Web-scraped data has unclear provenance
• Aggregated datasets obscure original sources
• Preprocessing steps may not be recorded
• Consent and licensing may be ambiguous

Best Practices:

1. Document data sources at collection time
2. Record all preprocessing transformations
3. Capture dataset statistics and distributions
4. Note known limitations and biases
5. Maintain clear licensing information

Detecting Malicious Model Artifacts¶

AI-BOMs enable security analysis of model artifacts, complementing the malicious model detection discussed in Book 1, Chapter 10.

Detection Approaches:

Format Analysis:

• Identify file format (pickle, SafeTensors, ONNX)
• Flag high-risk formats (pickle) for additional scrutiny
• Verify format matches claimed type

Content Scanning:

# Scan pickle files for code execution
picklescan --path model.pkl

# Scan model for secrets
detect-secrets scan model-config.json

# Verify SafeTensors integrity
python -c "from safetensors import safe_open; safe_open('model.safetensors', framework='pt')"

Provenance Verification:

• Verify cryptographic signatures
• Check provenance attestations
• Compare against known-good hashes

Behavioral Analysis:

• Test model in sandboxed environment
• Monitor for unexpected network activity
• Check for anomalous resource usage

AI-BOM Security Fields:

{
  "components": [
    {
      "type": "machine-learning-model",
      "name": "classifier",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "abc123..."
        }
      ],
      "properties": [
        {
          "name": "format",
          "value": "safetensors"
        },
        {
          "name": "security-scan-date",
          "value": "2024-01-15"
        },
        {
          "name": "pickle-scan-result",
          "value": "not-applicable"
        }
      ]
    }
  ]
}

Regulatory Drivers¶

Regulatory requirements increasingly mandate AI transparency, driving AI-BOM adoption.

EU AI Act (2024):

The EU AI Act entered into force on August 1, 2024, with requirements becoming applicable on a phased timeline—most obligations take effect in 2026, with additional later dates for some areas. Documentation obligations differ for high-risk AI systems (Article 11 / Annex IV) versus general-purpose AI model providers (Article 53 / Annex XI–XII).

Key documentation requirements include:

• Technical documentation throughout lifecycle
• Record-keeping of training, validation, and testing data
• Transparency obligations for certain AI systems
• Risk assessment and mitigation documentation

AI-BOM provides the foundation for meeting these requirements.

Specific Requirements:

Other Regulatory Drivers:

• FDA AI/ML guidance²: Nonbinding recommendations for AI/ML-enabled medical devices that shape expectations for submissions and lifecycle management
• NIST AI RMF³: Risk management framework
• China AI regulations: Algorithm registration requirements

Compliance Integration:

AI-BOM supports compliance workflows:

AI-BOM Generation
    │
    ├──► EU AI Act compliance reports
    ├──► FDA submission documentation
    ├──► Risk assessment evidence
    └──► Audit trail maintenance

Tooling Landscape¶

AI-BOM tooling is less mature than traditional SBOM tooling but developing rapidly.

Generation Tools:

Current Gaps:

• Automated model scanning: Limited tools for comprehensive model analysis
• Dataset lineage: Manual tracking required in most cases
• Training pipeline capture: Integration with ML platforms needed
• Cross-platform correlation: Linking models across registries

Emerging Solutions:

• ONNX Model Hub: Standardized model format with metadata
• Hugging Face Transformers: Model card generation utilities
• MLflow Model Registry: Model lifecycle management
• Weights & Biases: Experiment and artifact tracking

Recommendations¶

For ML Engineers:

1. Start documenting now. Even without formal AI-BOM tools, begin capturing model provenance, dataset sources, and training configurations.

2. Use SafeTensors. Prefer SafeTensors over pickle-based formats to avoid the common arbitrary-code-execution risk associated with pickle deserialization.

3. Track model lineage. Document base models, fine-tuning relationships, and version history.

4. Integrate with ML platforms. Use MLflow, Weights & Biases, or similar tools to capture training metadata systematically.

For Security Practitioners:

1. Extend SBOM programs to AI. Include AI-BOM in software inventory requirements. Don't treat models as black boxes.

2. Scan model artifacts. Implement pickle scanning and format verification for downloaded models.

3. Verify model provenance. Check signatures and attestations for models from external sources.

4. Assess dataset risks. Understand what data trained models you depend on.

For Compliance Teams:

1. Map regulatory requirements. Identify which AI transparency requirements apply to your organization and products.

2. Establish AI-BOM standards. Define organizational requirements for AI documentation before regulations force rushed adoption.

3. Build audit trails. Capture AI-BOM information contemporaneously; reconstructing history is difficult.

4. Prepare for EU AI Act. If selling AI systems in Europe, AI-BOM capability will be essential for compliance.

AI-BOM extends supply chain transparency to a new category of artifacts with distinct security and compliance considerations. While tooling and standards are still maturing, the regulatory trajectory is clear: organizations building and deploying AI systems will need to document what's in them. Starting now—even with imperfect tools—builds the institutional knowledge and practices that will be required when regulations fully take effect.