CycloneDX Machine Learning Bill of Materials

Description

A CycloneDX ML-BOM (machine-learning bill of materials) is a machine-readable inventory of what a model is made of, written in the CycloneDX standard (ECMA-424) so that tools as well as people can check it. It applies the software bill of materials, a structured list of the components in a piece of software, to models: the model is declared as a component of type machine-learning-model with its identifiers, version, supplier, licence and file hashes, together with the base models it was derived from (its pedigree), the datasets used to train and evaluate it with their source, classification and owners, the libraries it depends on, and an optional structured model card giving its task, architecture, performance metrics, intended uses and known limitations. The BOM is written at release, by hand or with a generator that reads the model's repository and metadata, checked against the CycloneDX schema, and can be signed. Consumers then query it, for example to find every deployed model that uses a dataset or library found to be compromised, or to check a supplier's declared datasets and licences before purchase. Unlike a model card or datasheet, written for people to read, or an experiment log or data version history, which stay with the team that built the model, it is a parts list in a fixed schema that travels with the model and can be matched against vulnerability records and file hashes, but it records what its author declares and verifies none of it.

Example Use Cases

Security

A bank keeps an ML-BOM for every deployed model, recording each base model by its Hugging Face package URL and revision, the fine-tuning datasets, the framework libraries and the file hashes. When a compromised base-model release or a vulnerability in a model-loading library is announced, its security team queries the BOMs to list the affected deployments within hours and decides which to withdraw or patch.

A hospital trust buying a diagnostic imaging model requires the supplier to deliver a signed ML-BOM with each version. Before the model enters clinical evaluation, the acceptance team checks the BOM's signature, compares its file hashes with the delivered files and checks the listed libraries against known-vulnerability records.

A software company generates an ML-BOM for each release of its customer-support assistant with an open-source generator, recording the base and embedding models, the quantised model file and the framework libraries with hashes. Its security team compares each new BOM with the previous release's to catch an unreviewed change of base model or library before the release ships.

Transparency

A government department procuring a document-classification model asks bidders for an ML-BOM whose model-card and dataset fields declare each training and evaluation dataset with its source, licence and owner, and the model's known technical limitations. Its assessors and later its auditors read and query these declarations to compare bids and to check what the chosen supplier said it used.

Limitations

It records what its author declares. Nothing in the format checks that the listed datasets were the ones used, that the model-card fields are true or that the list is complete, so a BOM is evidence that a disclosure was made, not that it is accurate. Hashes and a signature show that the document and the files it lists have not changed since it was written, which is a different thing.
Almost every field is optional: ECMA-424 requires a component's type and name and little else, so a BOM can pass schema validation while saying almost nothing. In a 2026 preprint that generated ML-BOMs with one open-source tool for about 98,000 Hugging Face models, every BOM had the required fields, but only 39% named a dataset, 17% listed technical limitations and 0.2% had a meaningful description. A claim needs the fields it relies on to be checked, not only schema validity.
Generators can fill only what they can read: hub metadata, model-card text and configuration files. Training data, fine-tuning history and settings that the publisher never wrote down stay empty, and for a model bought from a supplier the BOM is only as complete as the supplier chooses to make it.
Each BOM describes one version of one model. Fine-tuning, quantisation, a new framework release or a changed dataset needs a new BOM, and the ability to answer 'which of our models use this component?' when a compromise is disclosed depends on BOMs being regenerated and kept for every deployed version, which is a standing process cost rather than a one-off task.

Resources

Research Papers

CycloneDX v1.5 JSON Reference

Software Packages

cdxgen

Creates CycloneDX Bill of Materials (BOM) for your projects from source and container images. Supports many languages and package managers. Integrate in your CI/CD pipeline with automatic submissio...

Tutorials

Authoritative Guide to AI/ML-BOM: Drive Transparency, Compliance, and Security Across the AI Supply Chain

Documentations

ECMA-424: CycloneDX Bill of Materials Specification (2nd edition, December 2025)

Ecma International•Dec 1, 2025

CycloneDX is a modern standard designed to address the complexities of the software and system supply chain.

Related Techniques

Name	Description	Assurance Goals
AI FactSheets	AI FactSheets is a documentation practice in which the developer or supplier of an AI model or service answers a structured set of questions about it, modelled on the supplier's declarations of conformity that industries such as telecommunications and transport use to give written assurance, with evidence, that a product meets stated requirements. The questions cover the service's purpose and its intended and unsuitable uses, the datasets it was trained and tested on, its test methods and results (reported for groups such as age bands or genders where relevant), checks for bias, explainability, behaviour on data unlike its training data and robustness to adversarial attack, how user data is secured, and its lineage, such as when and how its models were retrained; 'N/A' and 'Proprietary' are allowed answers. Facts are gathered from the people in each role across the lifecycle (business owner, data scientist, model validator and operations engineer), and any change to the service produces a new version of the FactSheet while earlier versions are kept. The originating group's seven-step method designs the template with its readers: interview the people who will read the facts and those who will produce them, draft and trial a template of questions, have the real producers complete it, evaluate the result with its readers for content and presentation, and build further templates for other audiences such as a review board or regulator. Unlike a model card, which reports one model's intended use and evaluation to the people choosing it, or a datasheet, which describes one dataset, a FactSheet may cover one model or a whole service built from several models and datasets (attaching their datasheets), gathers facts from each role in the lifecycle and has a different template for each audience; unlike a CycloneDX ML-BOM it is written for people to read rather than as a machine-readable parts list for software tools.	Transparency
Malicious Model-File Scanning	Malicious model-file scanning checks a downloaded or received model file for code that would run when the file is loaded, without loading it. Several common ways of saving (serialising) models can carry such code, above all Python's pickle format, the default for PyTorch checkpoints and the usual format for scikit-learn models, whose files can instruct the loader to import and call any Python function, so that loading an untrusted file can hand an attacker control of the machine; since version 2.6 PyTorch's own loader by default allows only a small set of known-safe functions, but some libraries switch that off to load their models. The named method is ModelScan, an open-source scanner from Protect AI, which chooses a check by file extension and reads the file as data: for pickle-based files it lists the functions the file would import and compares them with a graded list of unsafe ones, such as the os, subprocess and socket modules and Python's built-in eval and exec, and for Keras and TensorFlow files it flags Lambda layers, which hold arbitrary Python, and operations that read or write files. It reports each finding with a severity from critical to low and exits with a non-zero code when it finds any, so a pipeline can stop the file before anything loads it. The evidence is a record that no listed unsafe call was found in the files scanned; unlike data-poisoning detection it examines the saved file rather than the training data, and it shows neither that the file is safe, nor how the model behaves, nor who produced the file.	Security
UK Algorithmic Transparency Recording Standard Record	An Algorithmic Transparency Recording Standard (ATRS) record is a public account that a UK public sector organisation writes about one algorithmic tool it uses, on the UK government's standard template, and publishes in a central repository on GOV.UK. The template has two tiers: a short plain-language summary for the general public (what the tool is, why it is used and a contact), and eight further sheets for specialist readers such as journalists, researchers and civil society, covering who is accountable for the tool and which suppliers were involved, how it works and what it replaced, how its output feeds into decisions, when a person reviews that output, how members of the public can appeal, the system's and each model's inputs, outputs, architecture and performance (including any bias testing), the data used, and the impact assessments, risks and mitigations. Information that would be exempt under the Freedom of Information Act can be left out or summarised field by field, with the reason stated, and the record is cleared by the tool's team, its senior responsible owner (the role accountable for the tool) and the press office, checked for readability by the central ATRS team, and updated when the tool changes substantially or is retired. Publishing is mandatory for central government departments and for arm's-length bodies that deliver public or frontline services or deal directly with the public, for tools in beta, pilot or production that significantly influence decisions affecting the public or interact with it directly; other public bodies may publish voluntarily. Unlike a model card, written by a developer for people choosing a model, or a supplier's AI FactSheet for buyers, an ATRS record is written by the deploying public body for the public and describes the decision process, human review and appeal routes around the tool as well as the tool.	Transparency