An AI SBOM for ML models stopped being a vendor slide in 2026 and became a documented baseline with named fields. On 12 May 2026 CISA and its G7 partners published Software Bill of Materials for AI - Minimum Elements, the first G7 guidance on the subject, which divides an AI system inventory into seven clusters and names thirteen elements the Models cluster should carry. Ten weeks later CISA shipped the 2026 Minimum Elements for a Software Bill of Materials, dated 29 July 2026, replacing the 2021 NTIA baseline for ordinary software. Read together they answer the question teams actually have: which fields go in the file, and which of them exist only because there is a model in the build.
The seven clusters, and the thirteen model fields
Start with the framing the full G7 document uses, because it kills a common mistake. AI systems are also software systems, so an SBOM for AI is additive: the model clusters sit on top of the general SBOM minimum elements, not instead of them. A repository that emits no conventional SBOM today does not get to skip that step by generating a model inventory.
The clusters are Metadata, System Level Properties, Models, Datasets Properties, Infrastructure, Security Properties, and Key Performance Indicators. Metadata describes the document (author, version, format name and version, author signature, tool name and version, generation context, timestamp, dependency relationship). The rest describe the system.
The Models cluster is the part with no equivalent in a package SBOM. Its elements are model name, identifier, version, timestamp, producer, description, hash value, hash algorithm, properties, input-output properties, training properties, license, and external references. Three of those carry most of the security weight:
- Model hash value and hash algorithm. The hash covers the weights or model file, and the guidance points authors at IANA Hash Function Textual Names for naming the algorithm. Without it you have a name and a version string, which is an inventory of labels, not artifacts.
- Model training properties. This covers pre-training and post-training, including fine-tuning stages, continual learning, and RLHF-style preference optimization. Lineage lives here: which predecessor checkpoint the model was fine-tuned or distilled from. That relationship is the one field that turns a poisoned-base-model disclosure into a bounded exposure query.
- Model license. Not just the SPDX identifier, but whether the model is open weight, open architecture, open data, or open training. Those four are different legal and operational facts and procurement will eventually ask about each.
The Datasets Properties cluster mirrors it for data: name, description, content, identifier, hash, provenance, statistical properties, sensitivity, dependency relationship, and license. Dataset provenance and sensitivity are the fields most teams cannot fill in retroactively, which is the argument for generating the document during the training run rather than during the audit.
CycloneDX ML-BOM or SPDX AI profile
The G7 document is format-agnostic by design. Two schemas implement it.
CycloneDX ML-BOM represents models, datasets, and configurations inside the same document structure as a normal CycloneDX SBOM. It is standardized as ECMA-424, whose second edition (December 2025) tracks CycloneDX 1.7. The 1.7 schema defines machine-learning-model and data as component types alongside library and container, and attaches a modelCard object with modelParameters, quantitativeAnalysis, considerations, and free-form properties. A minimal model component:
{
"type": "machine-learning-model",
"name": "support-triage-classifier",
"version": "3.1.0",
"hashes": [{ "alg": "SHA-256", "content": "0f3c...b91a" }],
"licenses": [{ "license": { "id": "Apache-2.0" } }],
"modelCard": {
"modelParameters": {
"approach": { "type": "supervised" },
"task": "text-classification",
"architectureFamily": "transformer",
"modelArchitecture": "distilbert-base-uncased",
"datasets": [{ "ref": "urn:cdx:dataset/internal-tickets-2026q1" }],
"inputs": [{ "format": "text/plain" }],
"outputs": [{ "format": "application/json" }]
},
"considerations": {
"technicalLimitations": ["English-only; degrades on ticket text over 512 tokens"]
}
}
}Note that datasets accepts either inline data or a ref to a separate data component. Use the reference form. One dataset feeding four models should be one component with four dependency edges, not four copies that drift apart.
SPDX 3.0.1 takes the other route with an AIPackage class in its AI profile, carrying typeOfModel, hyperparameter, modelDataPreprocessing, modelExplainability, safetyRiskAssessment, standardCompliance, useSensitivePersonalInformation, limitation, metric, metricDecisionThreshold, autonomyType, domain, plus a set of energy consumption properties broken out by training, fine-tuning, and inference. That energy split and the safetyRiskAssessment and standardCompliance fields tell you who SPDX is aimed at: assurance and regulatory reporting, where CycloneDX is aimed at security tooling. Pick on consumer, not on preference. The format and generator comparison goes deeper on tooling.
Generate at build, sign the artifact
The Metadata cluster includes a generation context element with values like “before build”, “build”, and “after build”. It exists because the field quietly grades your process. A BOM generated after build from a binary knows what shipped but little about how; a BOM generated from source knows the intent but not the artifact. For models, the useful moment is the training or packaging job, where the run has the dataset references, the hyperparameters, the base checkpoint, and the final file all in scope at once.
Hashes are what make the document verifiable, and a hash is only as good as its binding to an identity. sigstore/model-transparency signs model files and emits a Sigstore bundle containing a DSSE envelope with an in-toto statement, file hashes, and verification material, using keyless signing through Fulcio and Rekor or conventional keys and PKCS#11 devices. Verification recomputes the file hashes and compares them against the signed set. Pair that with the SBOM author signature element and the inventory becomes evidence instead of an assertion.
If your models live in an internal registry or a managed service rather than on Hugging Face, budget for glue code. Registry metadata to CycloneDX components is a mapping job nobody has generalized, and the export is where dataset references get dropped.
What the inventory buys you
The payoff is a query, not a document. When a vulnerability lands in a serving framework, a base checkpoint, or a dataset, the question is “where are we exposed, and how far does it propagate,” and only recorded lineage answers the second half. That workflow is the subject of a separate ML stack CVE triage guide, and the inventory is its first input. Feed it a disclosure stream such as ai-alert.org so an entry in your BOM becomes an alert when its upstream breaks.
Be clear about the limits. A BOM is an index, not a scanner. It will not tell you that a checkpoint carries a pickle deserialization payload, that a model repository was hijacked, or that anything drifted after deployment. The G7 elements are explicitly voluntary and create no requirement, standard, or legislation, though binding obligations under the EU AI Act and the Cyber Resilience Act are tracked separately at neuralwatch.org and will converge on the same fields. Generate the document for the models you already ship, then read the empty fields as a map of where your supply chain visibility stops. Most of those gaps belong to your suppliers, and model provenance on public hubs is where they show up first.
Related across the network
- CISA AI Security Guidance: What Organizations Need in 2026 — ai-alert.org
- AI-SBOM, AI-BOM and ML-BOM Tools Compared (2026) — bestaisecuritytools.com
