Build the AI bill of materials, build it in CycloneDX, and stop calling it an AIBOM. There are two schemas behind the five acronyms, not five artifacts. The file is worth producing because procurement will ask for it and the Cyber Resilience Act already compels its software half. It is not worth believing: a bill of materials attests inventory, never authorship or integrity, and no quantity of additional acronyms changes that.
SBOM for software, CBOM for cryptography, AIBOM for artificial intelligence, HBOM for hardware, QBOM for quantum. They arrive together, usually under the name xBOM, and the framing implies five specifications to comply with and five pipelines to build. Search any of those terms and the first page is content marketing from firms that sell bill-of-materials tooling, published as neutral explainers, glossaries and academies. None of it is treated as a source here. Where a claim exists only in vendor material this report labels it a vendor claim and names the product alongside it.
Read the specifications instead and the count collapses. CycloneDX 1.7, ratified as ECMA-424 second edition in December 2025, is one specification with one JSON serialization in which hardware devices, machine learning models, datasets and cryptographic assets are four values of a single component type enumeration. SPDX 3.0 arrives at the same structure through profiles layered on a common core. Two schemas and four domains, not five artifacts. The fifth acronym is worse off than that: the 566 pages of ECMA-424 contain no occurrence of the string QBOM, SPDX has no quantum profile, and the first cross-domain academic survey of the field searched five BOM categories that did not include it.
The commercial interest behind the framing is worth stating rather than burying. Delivery Shield, the application security posture management platform sold by OpsMx, markets continuous xBOM tracking across SBOM, CBOM and AIBOM through one dashboard, plus a deployment bill of materials of its own devising. OpsMx sells the aggregation layer, and a five-part framework is a larger aggregation layer than a one-part framework. That does not make the framing wrong. It does make the count a thing to verify.
Four primary specifications and guidance documents totalling roughly 750 pages were read rather than summarized, and several of the numbers below are word-boundary counts taken directly from those files. Specification text, regulatory text, government publications and peer-reviewed research are the sources. Vendor explainers are not.
CycloneDX 1.7, ratified as ECMA-424 second edition in December 2025, is a single specification with a single JSON serialization in which hardware devices, machine learning models, datasets and cryptographic assets are four values of one component type enumeration. SPDX 3.0 reaches the same place through profiles on a common core. The 566-page ECMA-424 text contains no occurrence of the string QBOM, and neither does the first cross-domain academic survey of the field, whose five searched categories are SBOM, CBOM, AIBOM, HBOM and SaaSBOM.
The Cyber Resilience Act requires a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies, names no format, and mentions no other bill of materials type. The AI Act's Article 11 and Annex IV require technical documentation in narrative form and use none of the acronyms. The strongest binding AI transparency obligation is Article 53(1)(d), which mandates a public prose summary on a Commission template, not a machine-readable inventory.
The G7 Cybersecurity Working Group's Software Bill of Materials for AI: Minimum Elements, published jointly by seven national cybersecurity agencies and the European Commission in 2026, defines seven clusters of elements across 26 pages and uses the term AIBOM zero times. So does CISA's 2026 Minimum Elements, co-signed by eighteen agencies, which states that it does not introduce additional elements for SBOMs for AI systems. The naming convention the agencies chose is SBOM for AI.
India's CERT-In, the only national authority that has formalized the term, defines a QBOM as an inventory of a quantum computing device: its processor, simulators, sensors, SDKs and energy consumption. Vendors selling post-quantum readiness tooling define it as an inventory of cryptographic algorithms scored for quantum vulnerability, which is a cryptography bill of materials under a different name. CERT-In itself gives QBOM and CBOM a single shared section and a single minimum-elements table.
The Log4j question is: which of my systems contain this component. It works because libraries are versioned, patchable and declared in manifests. Models are not patched, and the provenance an AI bill of materials would need is frequently absent at source. More than 60 percent of models and 70 percent of datasets on Hugging Face lack a complete model card. In an industrial case study, external APIs and scraping populated 40 percent of fields for third-party models. Even ImageNet and CIFAR-10 do not fully disclose their data sources.
ECMA-424 says so itself: the standard defines no enforcement mechanism for verifying the accuracy or completeness of a BOM. CISA's 2026 guidance places accuracy, coverage and completeness explicitly out of scope. The G7 authors write that an SBOM for AI by itself is not sufficient for increasing supply chain cybersecurity. Three independent bodies have documented the same limit, and the marketing around the five-part framework does not mention it.
Academic work published in 2025 identified 22 distinct pickle-based model loading paths across five major machine learning frameworks, of which 19 are missed entirely by existing scanners, and demonstrated 133 exploitable gadgets achieving close to a 100 percent bypass rate against available detection tools and 89 percent against the best of them. An inventory entry naming a model and a hash establishes which artifact you loaded. It does not establish that the artifact is what its publisher intended to ship.
Model Context Protocol server entries and project-scoped agent configuration files execute on folder-open and sit outside the dependency graph that software composition analysis inspects. Scanners for these files now exist, from Snyk, Cisco and others, but they emit findings rather than inventory: none of them produces a bill of materials. Snyk's aibom command is the only tool identified here that places MCP clients, servers and their exposed tools into a CycloneDX document.
CycloneDX carries the largest share of production use in the only independent adoption survey available, at 44 percent against SPDX's 29 percent. Both the OWASP AI bill-of-materials generator and Snyk's aibom command emit CycloneDX and neither emits SPDX. CycloneDX expresses AI, hardware and cryptography as component types in one document rather than requiring profile composition. Protobom and bomctl provide a conversion path that is close to lossless but not identical, so the decision is cheap to revisit and not free.
Generating a file in continuous integration is a solved problem and costs almost nothing. Keeping it true across every fine-tune, dataset refresh and prompt version, with a named owner accountable per model, is the cost that decides whether the program survives its second year. That cost scales with model count and is unaffected by the tooling decision, because no tool can discover a lineage its publisher never documented. Below roughly ten production models the correct answer is a maintained spreadsheet and no program at all.
The short list this analysis produces for anyone writing bill-of-materials requirements into a supplier agreement in the next twelve months. Require fields, not acronyms: a clause saying the supplier shall provide an AIBOM is unenforceable because the parties have no shared definition, whereas a clause listing the G7 model cluster elements and naming CycloneDX 1.7 is enforceable and testable.
Inventory of software components and their dependency relationships. Two mature schemas: ECMA-424 second edition and ISO/IEC 5962. A binding Cyber Resilience Act obligation from 11 December 2027, and eighteen-agency minimum elements guidance behind it.
Yes, with the format named
Inventory of cryptographic algorithms, keys, certificates and protocols. A component type in CycloneDX with a developed model. No binding obligation to produce the artifact, but a hard migration deadline that requires the underlying discovery: quantum-vulnerable public key algorithms are deprecated after 2030 and disallowed after 2035.
Yes as a discovery deliverable, not by that name
Inventory of models, datasets and their provenance. Real schema support in both CycloneDX and SPDX 3.0, and voluntary G7 minimum elements. No binding instrument uses the term, and the upstream metadata it would draw on is mostly absent.
Yes, as named fields plus a completeness score
Inventory of physical components in a hardware product. A component type in CycloneDX. CISA's 2023 framework is voluntary, is not a format, and maps its own fields one-to-one onto CycloneDX and SPDX, recording "None, do not map" where no mapping exists. It recommends merging itself into the SBOM frameworks.
Only if you buy hardware. Cite the CISA taxonomy
Contested. Either an inventory of quantum computing hardware you probably do not own, or a renamed CBOM. No specification from any standards body, two incompatible definitions in circulation, and one national advisory that gives it a shared table with CBOM. Two parties signing the clause would be agreeing to different deliverables.
No. Strike it
One thing to explicitly not require: a supplier warranty that models are free of poisoned weights or inherited vulnerabilities. No supplier can support that warranty on current detection technology, and asking for it produces either a refusal that delays the deal or an acceptance that is worthless. Ask instead for the weight hash where the supplier controls the artifact, an unknown declaration where it does not, and notification on model change. The report also costs the program: build is roughly 110,000 dollars a year fixed, buy is around 75,000, and both carry an identical 3,400 dollars per production model per year for named-owner upkeep. The lines never cross, which is the finding. Four scenarios run to 2029 with observable tripwires, and the two worth watching are a working group opening a quantum profile at Ecma TC54 or in SPDX, and a harmonised standard reference appearing in the Official Journal that names a BOM specification by number.
This isn't a vendor summary. Every sentence is labeled by what stands behind it: verified fact, vendor claim, third-party estimate, my assessment, hypothesis, or scenario. Sources are numbered and clickable. Forward-looking sections use scenarios with observable tripwires, not forecasts. It's the same method behind every market assessment I write.
Thirty-one pages, built from public sources with no client brief and no interviews. Read it in the browser or take the PDF.
Each report here answers a real question, directed and researched against public sources and evaluated against a stated assumption, then delivered as Word and PDF. If you're weighing a platform, sizing a category, or defending a number to a board, tell me the decision behind it and I'll tell you honestly whether a report is the right tool.
Commission an assessment