AI Bill of Materials Tools: AIBOM Formats and Generators

The honest state of AI bill of materials tools in 2026: two standards worth targeting, one free generator worth running today, and a commercial tier where “AIBOM” is usually a tab inside a larger AI security platform. The free option is the OWASP AIBOM Generator, an Apache-2.0 tool under the OWASP GenAI Security Project that takes a Hugging Face model ID and emits a CycloneDX 1.6 JSON document, complete with a completeness score telling you which fields you failed to fill. If you are evaluating tools because a customer questionnaire or an EU AI Act documentation request landed on your desk, start with the format decision, not the vendor decision. The format determines which tools can consume your output; get it wrong and you regenerate everything.

What an AI BOM has to capture

A classic SBOM inventories packages. An AI BOM inventories everything a model’s behavior depends on, which is a longer and stranger list. The SPDX project’s framing covers AI models, training data, production data, prompts, and AI agents. Palo Alto Networks’ primer defines it as “a machine-readable inventory that lists every dataset, model, and software component used to build and operate an AI system,” with model metadata (architecture, provenance, performance metrics), dataset metadata (source, licensing, preprocessing, bias annotations), and relationship fields linking models to the data they were trained on.

The relationship fields are the part that earns its keep. Knowing you ship some-embedding-model v2 is mildly useful. Knowing it was fine-tuned from a base checkpoint that later shows up in a poisoning disclosure is the actual security use case, and it only works if the lineage was recorded at build time. Nobody reconstructs training provenance retroactively.

Two formats, and how to choose

CycloneDX ML-BOM, from the OWASP ecosystem, represents datasets, models, and configurations for AI/ML systems, including dataset provenance and risk considerations around bias, data integrity, and model security. It lives in the same document structure as a regular CycloneDX SBOM, so a model can sit next to the Python packages that serve it. A trimmed component looks like this:

{
  "type": "machine-learning-model",
  "name": "bert-base-uncased",
  "modelCard": {
    "modelParameters": {
      "task": "fill-mask",
      "datasets": [{ "ref": "dataset-bookcorpus" }]
    }
  }
}

SPDX 3.0 took the other route: formal AI and Dataset profiles bolted onto the ISO-standardized SBOM format. The design work is documented in “Building an Open AIBOM Standard in the Wild”, an experience report from the SPDX side (authors include the Linux Foundation’s Kate Stewart) describing how more than 90 contributors extended ISO/IEC 5962:2021 to capture datasets and training artifacts, validated against regulations and practitioner interviews. That paper is worth reading before you commit to a format, because it is candid about what a standards body can and cannot get field consensus on.

The selection rule is the same one that settled the SBOM wars. CycloneDX when the consumer is your own security tooling and CI/CD. SPDX when the consumer is a regulator, an auditor, or a procurement office that says “ISO” in the first meeting. Both camps describe the formats as complementary, and for once that is not diplomatic spin: generating CycloneDX internally and mapping to SPDX for compliance artifacts is a workable pipeline.

The open-source tool to run first

The OWASP AIBOM Generator is the fastest way to see what an AIBOM looks like for a model you actually use. Point it at any Hugging Face model in owner/model form and it extracts the available metadata, emits CycloneDX 1.6 JSON, and scores the result for completeness with concrete recommendations. There is a hosted instance at owasp-genai-aibom.org if you want output before installing anything, and the CLI slots into CI for repeatable generation.

The completeness score is the diagnostic feature. Run it against your production models and watch how much comes back empty: undocumented training data, missing license fields, no provenance. That gap is not the tool’s failure. It is a measurement of how little metadata your model suppliers publish, which is precisely the information a procurement conversation needs.

The CycloneDX Tool Center lists the broader ecosystem, and generic BOM generators are growing ML awareness, but as of mid-2026 the honest coverage picture is thin. Model registry integrations exist unevenly. If your models live in SageMaker or an internal registry rather than Hugging Face, expect to write glue code that exports registry metadata into CycloneDX components yourself.

The commercial tier

The commercial pattern is consolidation: AIBOM generation bundled into AI security posture platforms rather than sold standalone. The clearest example is Palo Alto Networks, which completed its acquisition of Protect AI in July 2025 and folded its model scanning, posture management, and red-teaming work into Prisma AIRS. Protect AI was one of the earliest vendors treating the ML supply chain as an attack surface, so an inventory capability with scanning attached is the natural product shape.

Evaluate any commercial claim against four questions. Does it emit a standard format (CycloneDX or SPDX) you can take with you, or a proprietary inventory you cannot? Does it discover models automatically from your registries and pipelines, or only catalog what you hand-enter? Does it record dataset lineage, or just model names? And does it diff BOMs across versions, so a swapped base model or dataset shows up as a change event? A dashboard that fails the first question is shelfware with a renewal date.

What a BOM will not do

An AIBOM is an inventory, not a scanner. It will not tell you a serialized checkpoint carries a pickle deserialization payload, that your base model has a published vulnerability, or that the model drifted after deployment. Detection is the job of the scanners and supply chain tools reviewed separately, and file-level checks depend on which model format you ship. The BOM is the index that makes those checks actionable: when a model-level CVE or poisoning disclosure drops, it is how you answer “are we exposed” in minutes instead of weeks, and it is the first input to an ML stack CVE triage workflow. Pair it with a disclosure feed such as https://ai-alert.org/ to know when an entry in your inventory becomes a liability, and with runtime monitoring of the kind covered at https://sentryml.com/ to catch the failures no static inventory can.

The tooling is younger than vendor marketing implies, but the sequencing is settled: pick a format, generate BOMs for what you already ship, and let the empty fields tell you where your supply chain visibility actually ends.

Related across the network

• LLM Security Risks: A Practitioner’s Field Guide — ai-alert.org
• Machine Learning Security: Threats, Frameworks, and Defenses — ai-alert.org
• A Practical Guide to AI Red-Teaming for Security Teams — ai-alert.org
• AI Risks: A Practitioner’s Taxonomy for Security Teams — ai-alert.org
• AI Security: Attack Categories, Defense Gaps, and How to Respond — ai-alert.org