AI-BOMs in practice: documenting models and datasets with CycloneDX ML-BOM and SPDX 3.0

An AI bill of materials (AI-BOM) is a machine-readable inventory of everything an AI system is built from: the models, the datasets they were trained or tuned on, and the software that loads and serves them, with a hash and provenance for each. Two open standards can carry it today: CycloneDX, which added ML-BOM support in version 1.5, and SPDX 3.0, which added AI and Dataset profiles. The practical goal is simple: when a model, dataset, or library turns out to be compromised, you can answer "where do we use it?" in minutes, and your pipeline can refuse to deploy an artifact that does not match what was reviewed.

This article covers what an AI-BOM should record, how each standard represents it, and how to make the BOM enforceable instead of decorative.

Why does an AI system need more than a normal SBOM?

A software bill of materials lists packages and versions. That covers the inference server and its Python dependencies, but it misses the parts that most often determine an AI system's behavior and risk:

• Model weights. A checkpoint is a large binary that a normal package scanner does not see. A pickle-based file can also execute code on load (see loading third-party model weights safely).
• Lineage. A fine-tuned model inherits the properties of its base model and its training data. Neither shows up in a dependency tree.
• Datasets. Training and evaluation data carry licensing, personal data, and bias questions that auditors and data protection teams will ask about.

The OWASP Top 10 for LLM Applications addresses this under LLM03:2025 Supply Chain. It recommends keeping an up-to-date, accurate, and signed inventory of components using an SBOM, notes that model cards offer no guarantees about a model's origin, and states that AI BOMs and ML SBOMs are an emerging area where teams should evaluate options starting with OWASP CycloneDX.

An AI-BOM is not a replacement for an organizational model inventory. The inventory answers governance questions such as owner, purpose, and risk tier across the company (see a practical AI model inventory). The AI-BOM is the per-system technical record that the inventory can point to.

What should an AI-BOM record?

For every AI system, record at least the following. Keep it to what you can verify; an empty field is better than a guessed one.

Hosted model APIs deserve a line even though there is no file to hash. If a provider or gateway in your request path is compromised or changes behavior, the BOM should tell you which systems depend on it.

How does CycloneDX represent models and datasets?

CycloneDX introduced ML-BOM in version 1.5, announced on June 26, 2023. The standard is now also published by Ecma International as ECMA-424, whose 2nd edition (December 2025) defines CycloneDX 1.7.

The CycloneDX 1.6 JSON reference defines the pieces you need:

• Component type values machine-learning-model and data, alongside the familiar library and application.
• A modelCard object on a model component, with modelParameters (including approach, task, architectureFamily, modelArchitecture, datasets, inputs, and outputs), quantitativeAnalysis with performanceMetrics, and considerations (including useCases, technicalLimitations, and ethicalConsiderations).
• Dataset entries with fields such as type, name, classification, sensitiveData, and governance.
• The standard hashes array and pedigree object, which records ancestors, variants, and other lineage.

A trimmed example for a fine-tuned support classifier:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-ticket-router",
      "name": "ticket-router",
      "version": "2026.10.2",
      "hashes": [
        { "alg": "SHA-256", "content": "9f2c...e41a" }
      ],
      "pedigree": {
        "ancestors": [
          { "type": "machine-learning-model", "name": "example-base-model", "version": "1.0" }
        ]
      },
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "task": "text-classification",
          "datasets": [
            {
              "type": "dataset",
              "name": "support-tickets-2026q3",
              "classification": "confidential"
            }
          ],
          "inputs": [{ "format": "text/plain" }],
          "outputs": [{ "format": "application/json" }]
        },
        "considerations": {
          "useCases": ["Route inbound support tickets to a queue"],
          "technicalLimitations": ["Not evaluated on non-English tickets"]
        }
      }
    }
  ]
}

The hash in the example is shortened for readability. A real content value must be the full hex digest, 64 characters for SHA-256.

How does SPDX 3.0 represent AI systems?

The Linux Foundation released SPDX 3.0 on April 16, 2024, adding profiles for use cases including AI model training and characterization and dataset provenance.

In the SPDX 3.0.1 model, the AIPackage class describes a model or AI system. Its fields lean toward governance: autonomyType, domain, energyConsumption, hyperparameter, informationAboutTraining, limitation, metric, modelExplainability, safetyRiskAssessment, standardCompliance, typeOfModel, and useSensitivePersonalInformation, among others. The DatasetPackage class adds dataset fields such as datasetType, dataCollectionProcess, intendedUse, knownBias, hasSensitivePersonalInformation, and anonymizationMethodUsed.

Which standard should you pick?

Pick the one your existing SBOM tooling already produces and consumes. If your security team already ingests CycloneDX for vulnerability management, extend that pipeline with ML components. If your compliance or open source program office runs on SPDX, use its AI and Dataset profiles. As a rough guide, which is our opinion rather than a rule in either standard:

• CycloneDX's modelCard maps closely to model cards that engineering teams already write.
• SPDX's AIPackage has explicit fields for safety risk assessment, autonomy, and sensitive personal data, which map well to governance questionnaires.

Generating both from one internal source of truth is reasonable if different consumers need different formats. Maintaining two hand-written documents is not.

How do you make an AI-BOM enforceable?

A BOM that nobody checks is documentation. Three controls turn it into a safeguard.

1. Verify hashes before deployment

Fail the deploy when the model file on disk does not match the BOM. This catches swapped checkpoints, partial downloads, and a model pulled from the wrong source.

import hashlib, json, sys
from pathlib import Path

def sha256(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for chunk in iter(lambda: f.read(1 << 20), b""):
            h.update(chunk)
    return h.hexdigest()

bom = json.loads(Path("ai-bom.cdx.json").read_text())
artifacts = {"ticket-router": Path("models/ticket-router.safetensors")}

failed = False
for comp in bom["components"]:
    if comp["type"] != "machine-learning-model" or comp["name"] not in artifacts:
        continue
    expected = {h["content"] for h in comp.get("hashes", []) if h["alg"] == "SHA-256"}
    actual = sha256(artifacts[comp["name"]])
    if actual not in expected:
        print(f"hash mismatch for {comp['name']}: {actual}")
        failed = True

sys.exit(1 if failed else 0)

2. Sign the BOM

OWASP LLM03 calls for a signed inventory. Sign the BOM file in the same release step that builds the model artifact, and verify the signature before the hash check above. Otherwise an attacker who can replace the model can also replace the BOM.

3. Use it during incidents

The test of an AI-BOM is the next supply chain incident. When a popular package or gateway is compromised, as with the LiteLLM 1.107.0 release, you should be able to search every BOM for the affected component and version and get a list of systems and owners. Run that query as a drill once a quarter before you need it.

Where do AI-BOMs fit in compliance work?

Regulators and customers increasingly ask for documentation of the models and data behind AI systems. An AI-BOM does not by itself satisfy any specific legal requirement, and this article is not legal advice. What it does is give you a consistent, versioned technical record that technical documentation, vendor questionnaires, and risk assessments can draw on, instead of rebuilding the same answers by hand each time.

Start small: one production AI system, its deployed model with hashes, its base model, its datasets, and a CI check. Then extend the pattern to every system in your model inventory.