An ML-BOM is a bill of materials that covers the model itself, not just the code around it. At minimum, record the model identity and exact version, its source and hash, the base model it came from, the datasets you know about, the license, and the software dependencies that load and serve it.
What the standards say they cover
CycloneDX describes its ML-BOM capability as representing datasets, models and configurations for AI and machine learning systems. Its page mentions dataset provenance, model training approaches, AI framework configuration and dependencies. I could not find a field list on that page, so check the current specification before you build tooling.
The SPDX 3.0.1 AI profile is described as a standard way to document AI software packages, covering AI system and model artifacts such as software packages, models and datasets. Its property list includes autonomyType, domain, hyperparameter, informationAboutTraining, limitation, metric, modelDataPreprocessing, safetyRiskAssessment, standardCompliance, typeOfModel and energy consumption fields. The page also states that each AI package needs exactly one declared license and one concluded license relationship. I could not confirm from that page which properties belong to which class, so verify against the class pages.
A practical field list
Whatever format you pick, these are the facts a reviewer will want.
- Identity: model name, version, and the exact revision or commit.
- Source: where you downloaded it, and when.
- Integrity: file names with hashes, and signature details if any exist.
- Lineage: the base model, and whether this is a fine-tune, adapter, merge or quantized version.
- Data: training datasets you can name, and a note where the author gave none.
- License: model license and any dataset licenses, with a link to the text.
- Intended use and limits: copied from the model card, with the date you read it.
- Format: safetensors, pickle based or other.
- Runtime dependencies: the libraries that load and serve it, with versions.
- Evaluation: your own test results and who ran them.
Where each fact comes from
Model card metadata on the Hub can supply the license, datasets and base model fields, when authors fill them in. Your own download step supplies hashes and revision. Your package manifests supply the library list. Your evaluation runs supply the test results.
Mark anything unknown as unknown. A blank is a finding, not a failure of the document.
Keep it current
A model entry goes stale like any dependency. Update it whenever you change the revision, retrain, or swap a library version. Store it next to the code that deploys the model so reviews catch drift.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning covers the software side of that list, the packages around your models. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Do I need an ML-BOM if I only call a hosted model API?
You still benefit from recording which model and version you depend on, plus the licence and data terms. The file hashes part applies when you hold the weights yourself.
Which format should I choose?
Pick the one your downstream tools and customers already read. CycloneDX and SPDX 3 both describe AI components.
Sources
Last reviewed: 19 October 2026.
