What Is an ML-BOM? Machine Learning Bill of Materials Explained

A machine learning bill of materials (ML-BOM) is a structured, machine-readable inventory of every component that goes into an AI model: the model's identity and version, its architecture family, the datasets it was trained and evaluated on, its software dependencies, licenses, evaluation results, and the cryptographic signatures that prove none of it has been altered. Just as a software bill of materials (SBOM) lists the packages inside an application, an ML-BOM documents the full supply chain of a machine learning system — so security teams, auditors, and regulators can see exactly what a model is made of without needing access to the model itself.

The term AI-BOM is often used interchangeably with ML-BOM. Both describe the same artifact class: a transparency document for AI systems, standardized primarily through CycloneDX (which added ML-BOM support in version 1.5) and the SPDX AI profile. This guide covers what an ML-BOM contains, how the two standards compare, how ML-BOMs differ from SBOMs, and how they are generated and signed in practice.

Why do ML-BOMs exist?

ML-BOMs emerged because three pressures converged on AI teams at roughly the same time: supply chain risk, regulation, and management-system standards.

AI supply chain risk

Modern models are rarely built from scratch. They are fine-tuned from pretrained checkpoints, trained on third-party or scraped datasets, and assembled from open-source frameworks and libraries. Every one of those inputs is an attack surface. MITRE ATLAS, the adversarial-threat knowledge base for AI systems, catalogs techniques that target exactly this supply chain — poisoned training data, backdoored pretrained models, and compromised ML dependencies. Without an inventory of what went into a model, you cannot answer the most basic incident-response question: are we affected? When a dataset is found to be poisoned or a model repository is compromised, an ML-BOM lets you query your entire model estate for exposure in minutes rather than weeks. (For how ATLAS threat categories map to management controls, see our ISO 42001 to MITRE ATLAS crosswalk.)

EU AI Act transparency obligations

The EU AI Act entered into force in August 2024, with obligations phasing in over the following years. Providers of high-risk AI systems must maintain technical documentation describing how the system was developed, what data it was trained on, and how it performs — and keep that documentation current across the system's lifecycle. The Act does not name a file format, but a machine-readable, versioned ML-BOM is the most defensible way to demonstrate that this documentation exists, is complete, and has not been edited after the fact.

ISO/IEC 42001 documentation duties

ISO/IEC 42001:2023, published in December 2023, is the first certifiable management system standard for AI. Its Annex A controls cover themes such as AI system documentation, data provenance and quality, impact assessment, and supplier management. Auditors assessing an AI management system need evidence that the organization actually knows what its models are made of. An ML-BOM is that evidence in its most concrete form. Our ISO/IEC 42001 explainer walks through the standard's structure in detail.

What does an ML-BOM contain?

A complete ML-BOM records seven categories of information. The exact field names differ between CycloneDX and SPDX, but the substance is the same:

A crucial point: an ML-BOM contains metadata about these components, not the components themselves. Model weights, training records, and source code never need to appear in the document. That is what makes ML-BOMs shareable with auditors, customers, and regulators without leaking intellectual property — and it is the principle behind metadata-only compliance architectures.

CycloneDX vs SPDX: which ML-BOM standard should you use?

Two open standards dominate the space. CycloneDX, an OWASP flagship project, added first-class ML-BOM support in version 1.5 (2023) with a machine-learning-model component type, a data component type for datasets, and an embedded model card structure. SPDX, a Linux Foundation project and ISO-published SBOM standard, introduced an AI profile and a dataset profile in SPDX 3.0 (2024).

The pragmatic answer for most organizations is both. The two formats are complementary — CycloneDX is stronger for security-driven workflows, SPDX for license governance — and because both are generated from the same underlying metadata, tooling can emit the two in parallel. SecureGRC's ML-BOM generation aligns with both CycloneDX and SPDX for exactly this reason.

What does a real CycloneDX ML-BOM look like?

Below is a realistic, minimal CycloneDX 1.5 ML-BOM for a fraud-detection classifier. It records the model, its training dataset (as metadata only), and one library dependency with its license:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-07-17T09:00:00Z",
    "component": {
      "type": "machine-learning-model",
      "name": "fraud-detection-classifier",
      "version": "2.4.1"
    }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "model-fraud-detection-2.4.1",
      "name": "fraud-detection-classifier",
      "version": "2.4.1",
      "modelCard": {
        "modelParameters": {
          "task": "binary-classification",
          "architectureFamily": "gradient-boosted-trees",
          "datasets": [
            { "ref": "dataset-transactions-2025q4" }
          ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "AUC-ROC", "value": "0.94", "slice": "holdout-test" }
          ]
        }
      }
    },
    {
      "type": "data",
      "bom-ref": "dataset-transactions-2025q4",
      "name": "transactions-2025q4",
      "data": [
        {
          "type": "dataset",
          "classification": "internal",
          "sensitiveData": ["pseudonymized transaction records"]
        }
      ]
    },
    {
      "type": "library",
      "name": "xgboost",
      "version": "2.0.3",
      "licenses": [
        { "license": { "id": "Apache-2.0" } }
      ]
    }
  ]
}

Notice what is absent: no weights, no training rows, no feature code. The dataset entry describes classification and sensitivity, and the model entry describes architecture and measured performance. Everything a reviewer needs; nothing an attacker or competitor could exploit.

How is an ML-BOM different from an SBOM?

An ML-BOM extends the SBOM idea, but the two documents answer different questions and change at different rhythms. An SBOM asks "what packages are in this build?"; an ML-BOM asks "what model is this, what shaped its behavior, and can you prove it?"

The practical consequence of the "change trigger" row is easy to underestimate. Software rebuilds when engineers ship; models retrain on schedules, on drift alerts, and on new data drops. An ML-BOM maintained by hand is therefore stale almost immediately — which leads directly to the generation question.

How are ML-BOMs generated?

There are two approaches, and the gap between them is where most AI transparency programs fail.

Manual assembly

Teams document models in spreadsheets, wikis, or hand-written model cards, then transcribe the results into CycloneDX or SPDX. This works for a demo and fails in production: fields go stale after the first retrain, human transcription introduces errors, and nothing links the document back to the actual model artifact. A manually assembled ML-BOM is a statement of intent, not evidence.

Automated extraction

The sustainable approach is to extract metadata programmatically — from training pipelines, model registries, experiment trackers, and dependency manifests — and generate the ML-BOM as a build artifact, versioned and regenerated on every model change. Automation keeps the document synchronized with reality and makes every field traceable to a source.

This is the approach SecureGRC takes, with one architectural constraint that matters for IP-sensitive teams: the platform is metadata-only. Model weights, training data, and proprietary code never enter SecureGRC; the analysis pipeline operates exclusively on extracted metadata, as described in our metadata-only compliance deep dive. That metadata then flows through the TCCE engine — threat assessment, control mapping, compliance evaluation, and evidence linking as a sequential, independently auditable pipeline — so the generated ML-BOM arrives already connected to MITRE ATLAS threat profiles and ISO/IEC 42001 control gaps, and browsable in a dedicated ML-BOM Explorer. SecureGRC is a purpose-built, early-stage platform opening early access in 2026 — a deliberate contrast to retrofitting AI inventories onto broad GRC suites, as our SecureGRC vs OneTrust comparison discusses.

Why sign an ML-BOM with post-quantum signatures?

An unsigned ML-BOM is a claim; a signed one is audit evidence. A cryptographic signature over the document proves two things: integrity (no field was altered after generation) and origin (it was produced by the stated system at the stated time). For regulators and auditors, that distinction is the difference between "trust our spreadsheet" and independently verifiable proof.

The quantum dimension comes from timescales. Compliance evidence for AI systems must remain verifiable for years — through audits, certifications, incidents, and litigation. Classical signature schemes based on RSA and elliptic curves are exactly what a future cryptographically relevant quantum computer would break, meaning evidence signed today with classical algorithms could become repudiable within its own retention window. NIST addressed this by standardizing post-quantum algorithms, including FIPS 204 (ML-DSA, the standardized form of CRYSTALS-Dilithium), finalized in August 2024.

SecureGRC applies this end to end: every generated artifact — ML-BOMs included — is signed with CRYSTALS-Dilithium, hashed with SHA-3, and anchored in a Merkle tree, forming a cryptographically verified audit trail. Verification requires only public keys, so an auditor or regulator can independently confirm that an ML-BOM is authentic and unmodified without any access to SecureGRC's systems — or yours. The full rationale is covered in our quantum-safe compliance guide.

Frequently asked questions

Quick answers to the ML-BOM questions we hear most. More general questions live on the SecureGRC FAQ.