Key takeaways
- A sourcing note: CycloneDX's capabilities page and the SPDX 3.0.1 specification pages were fetched directly.
- Record model identity first: version, a content hash, and where the model file actually lives in the firmware image — the same baseline discipline firmware SBOM applies to every other component.
An AI-BOM (AI bill of materials — CycloneDX's own implementation calls it an ML-BOM, machine learning bill of materials) is a structured, machine-readable inventory of the models, training data and AI-specific configuration a piece of software or firmware embeds, built on the same idea as a software SBOM but aimed at a component a software SBOM doesn't describe: a trained model baked into the device itself. As more devices run inference on-device rather than only in the cloud, that gap matters for exactly the same reasons a missing software SBOM does — you can't assess, patch or disclose a component you haven't inventoried.
A sourcing note: CycloneDX's capabilities page and the SPDX 3.0.1 specification pages were fetched directly. The OWASP CycloneDX Authoritative Guide to AI/ML-BOM and the Linux Foundation's SPDX AI-BOM research paper are large PDFs that this guide's fetch tooling could not fully render as extractable text; facts attributed to them are cross-checked against the directly fetched specification pages and GitHub release history above. Confirm field-level detail against those primary documents before treating this guide as authoritative on any single schema field.
Why a software SBOM doesn't cover an embedded model
A software bill of materials — see firmware SBOM for how that works on an embedded image without source access — answers "what packages and versions make up this build." It has no concept of a trained model: a binary blob of weights that was produced by a training process, on a specific dataset, to do a specific job, with specific documented limitations. A device that embeds an on-device model for object detection, wake-word recognition, anomaly scoring or similar has real supply-chain and disclosure surface in that model that a software SBOM simply doesn't have a field for — which dataset trained it, whether that dataset's license or provenance is clean, what the model was validated to do versus what it's actually used for in the field, and what inference runtime (and that runtime's own dependencies) loads and executes it.
Two independent standards, two different starting points
CycloneDX, an OWASP project and Ecma International standard now at v1.7 (October 2025, Ecma-424 2nd edition), added machine learning support in v1.5 (released 26 June 2023): a machine-learning-model component type sitting alongside the software components CycloneDX already modeled, and a model-card external-reference type whose schema describes covering "the intended uses of a machine learning model, potential limitations, biases, ethical considerations, training parameters, datasets used to train the model, performance metrics, and other relevant data useful for ML transparency." ML-BOM sits in the same family as CBOM (see cryptographic bill of materials), HBOM and SaaSBOM — CycloneDX's broader approach of extending one document model to cover different kinds of components rather than inventing a separate standard per component type.
SPDX 3.0.1 took a parallel but independent path: its AI profile defines an AIPackage class the spec itself summarizes as a class that "specifies an AI package and its associated information," providing metadata that can be added to a package to describe an AI application or trained model. Its properties include domain, autonomyType, standardCompliance and typeOfModel, plus two fields with no real CycloneDX equivalent: energyConsumption (training and inference energy use) and safetyRiskAssessment, an enumerated High/Medium/Low/Serious categorization the spec ties explicitly to Article 20 of EC Regulation No 765/2008 on accreditation and market surveillance. Neither format is currently named as mandatory by a device-security regulation — see CycloneDX vs SPDX for how the same two-standard situation already plays out for ordinary software SBOMs.
Where this actually matters for a device maker
SoftWSP's own firmware security assessment already treats this as a distinct check, separate from the software SBOM: unpacking an image to look for "AI models, inference runtimes and API keys or tokens embedded in the image," listed in an AI bill of materials alongside the software SBOM. That reflects a real shift — on-device inference in cameras, voice-enabled appliances, predictive-maintenance sensors and industrial gateways means the model and its runtime are now part of what ships, not an external service call a software SBOM would already catch. Where that device also meets the definition of a high-risk AI system under a regime like the EU AI Act, its documentation duties around training data and methodology add a legal reason to have this inventory, on top of the security one.
A workable starting point
Record model identity first: version, a content hash, and where the model file actually lives in the firmware image — the same baseline discipline firmware SBOM applies to every other component. Capture training-data provenance and license, even at a summary level, before a customer or auditor asks and you have to reconstruct it after the fact. Keep the model card fields— intended use, known limitations, documented biases — next to the model, not in a separate document nobody updates when the model changes. Track the inference runtime as a normal software component: it has its own version, its own CVEs, and belongs in the same SBOM process as everything else in the image. Flag embedded AI API keys or cloud-inference endpoints explicitlyA key baked into firmware is a credential-management problem with the same blast radius as any other hard-coded secret. Reuse your existing SBOM tooling if you canIf you already emit CycloneDX, adding ML-BOM components to the same document is less overhead than adopting a second, AI-only format.
An AI-BOM is a young, two-standard space — neither CycloneDX's ML-BOM nor SPDX's AIPackage profile is mandated by name in a device-security regulation yet — but the underlying question it answers (what model is actually running on this device, where did it come from, and what does it depend on) is not optional just because the format is still settling. SoftWSP's firmware security assessment already checks for embedded models, inference runtimes and AI API keys as part of a standard scan: see device firmware security.
This guide draws on CycloneDX's own published capability page and GitHub release history (fetched directly) and the SPDX 3.0.1 specification's AIPackage class page (fetched directly), cross-checked against the OWASP CycloneDX Authoritative Guide to AI/ML-BOM and Linux Foundation Research's SPDX AI-BOM paper where those primary PDFs could not be rendered as extractable text. This guide is not a substitute for the CycloneDX or SPDX specifications themselves, or a specific regulation's own documentation requirements.
Sources
- CycloneDX: AI/ML-BOM capability (cyclonedx.org)
- OWASP CycloneDX: Authoritative Guide to AI/ML-BOM (PDF)
- CycloneDX/specification: Releases (GitHub) — v1.5 (26 June 2023) ML-BOM addition, current v1.7
- SPDX Specification 3.0.1: AIPackage class (AI profile)
- Linux Foundation Research: Implementing AI Bill of Materials (AI BOM) with SPDX 3.0
Frequently asked questions
What is an AI-BOM, and how is it different from a regular SBOM?
A software bill of materials lists the packages, versions and licenses that make up a piece of software — exactly what [firmware SBOM](/guides/firmware-sbom/) covers for an embedded image. It says nothing about a trained machine learning model that firmware might also embed: which dataset trained it, what it was built to do, what its documented limitations or biases are, or what runtime loads and executes it. An AI-BOM (CycloneDX calls its implementation an ML-BOM, Machine Learning Bill of Materials) extends the same component-inventory idea to that model. CycloneDX's own capabilities page describes the goal as "model and dataset transparency for security, privacy, safety and ethical considerations," covering datasets (with their provenance and ethical considerations), models (training methodology and configuration) and the AI frameworks that run them — the same kind of structured, machine-readable inventory a software SBOM provides, aimed at a different kind of component.
Which standard actually defines an AI-BOM — CycloneDX or SPDX?
Both, as separate, independently maintained extensions to formats SoftWSP's audience likely already produces software SBOMs in. CycloneDX, an OWASP project and Ecma International standard (Ecma-424), added machine learning support in version 1.5, released 26 June 2023: a dedicated machine-learning-model component type, and a model-card external-reference type the schema describes as covering "the intended uses of a machine learning model, potential limitations, biases, ethical considerations, training parameters, datasets used to train the model, performance metrics, and other relevant data useful for ML transparency." The current specification is v1.7 (October 2025). Separately, SPDX 3.0.1 defines an AIPackage class in its AI profile, which its own specification summarizes as a class that "specifies an AI package and its associated information," with properties including domain, autonomyType, standardCompliance, typeOfModel, and two notable fields: energyConsumption (training and inference energy use) and safetyRiskAssessment (a High/Medium/Low/Serious categorization the spec ties to Article 20 of EC Regulation No 765/2008). As of today neither format is named as mandatory by a specific device-security regulation — they are the two concrete, machine-readable candidates a buyer, auditor or regulator asking for AI transparency can point at, much as [CycloneDX and SPDX](/guides/cyclonedx-vs-spdx-sbom-formats/) are for software SBOMs generally.
Why would a device or firmware maker need an AI-BOM specifically?
Because more devices now ship with an embedded model doing real work on the device itself — on-device object or anomaly detection in a camera, wake-word and voice processing in a smart speaker or appliance, predictive-maintenance scoring in an industrial sensor or gateway — and none of that is visible in a conventional software SBOM. The model file, any bundled or referenced training/fine-tuning data, the inference runtime (such as a TensorFlow Lite, ONNX Runtime or vendor-specific library) and any API keys or endpoints the firmware uses to reach a cloud inference service are all supply-chain surface a software-only SBOM misses entirely — which is exactly why SoftWSP's own firmware security assessment treats "AI models, inference runtimes and API keys or tokens embedded in the image" as a distinct check alongside the software SBOM, not a subset of it. Where a product also happens to be a high-risk AI system under a regulation like the [EU AI Act](/guides/eu-ai-act-cybersecurity-requirements/), the documentation duties that regime imposes on training data and methodology are a separate, legal driver pointing at the same underlying inventory.
What should a device maker actually record in an AI-BOM today?
Start with what both standards already define fields for, even before picking one: the model's identity, version and a content hash; where its training or fine-tuning data came from and under what license or usage terms; its documented intended use and known limitations (the same information a model card captures); the inference runtime and any software dependencies it pulls in, which belong in a software SBOM either way; and whether the firmware calls out to a hosted inference API, and with what credential. If the device maker already emits CycloneDX SBOMs for its firmware, adding ML-BOM's machine-learning-model components to the same document is the lower-effort path, since a CycloneDX AI-BOM is, in practice, an ML-BOM emitted in the same document model as the software SBOM — one inventory covering both, rather than two separate processes to maintain. [Cryptographic bill of materials](/guides/cryptographic-bill-of-materials-cbom/) is the closest precedent for how fast a narrow, device-focused BOM extension can go from "optional CycloneDX feature" to something buyers and regulators specifically ask for by name.
In this cluster
