77. OWASP AIBOM Generator Explained: How to Create an AI‑SBOM (CycloneDX) for a Model — and What to Do With It

Last Updated: June 6, 2026

The OWASP AIBOM Generator is the open-source tool that translates AI supply chain transparency from a compliance aspiration into a practical, automated workflow. Now a core initiative within the OWASP GenAI Security Project following its December 2025 migration, the tool extracts metadata from AI models hosted on Hugging Face and generates a standards-aligned AI Bill of Materials (AIBOM) in CycloneDX 1.6 JSON format — complete with a completeness scoring system that tells you exactly which fields are populated and which require manual input. In 2026, three forcing functions have converged to make AIBOM generation no longer optional: EU AI Act Article 11 and Annex IV technical documentation requirements for high-risk AI systems took effect August 2, 2026; CycloneDX ML-BOM v1.7 and SPDX 3.0 AI Profile matured into stable procurement-contractable formats; and enterprise procurement teams are beginning to require AIBOM documentation as a vendor qualification condition — treating it as the AI equivalent of a SOC 2 report.

This guide is the most complete practical resource for the OWASP AIBOM Generator in 2026. It covers what the tool actually produces, a five-step usage guide from installation through storage and sharing, an annotated field-by-field walkthrough of the CycloneDX AI-SBOM output, how to integrate AIBOM generation into your CI/CD pipeline, and how to troubleshoot the most common errors security teams encounter. This article is written for security engineers, compliance officers, AI governance leads, and MLOps practitioners who need to produce AI-SBOM documentation — not a conceptual overview of why AIBOM matters. If you need the foundational context on the AI System Bill of Materials concept before diving into the tool, our guide to the AI System Bill of Materials explained covers the what and why in full depth before you get to the how in this article.

The regulatory pressure behind AIBOM generation intensified significantly in 2026. OWASP LLM03 (Supply Chain Vulnerabilities) — which moved from #5 in 2023 to #3 in the 2025 edition — specifically cites AIBOM as the primary transparency control for AI supply chain risk management. An AIBOM provides the inventory needed to track what is in your AI stack, detect compromised components, and respond to supply chain incidents. Without one, you cannot determine whether a newly disclosed model-level vulnerability affects your deployment, cannot assess the blast radius of a compromised inference API, and cannot produce the technical documentation required by the EU AI Act or the NIST AI RMF. The parallel to the Log4Shell crisis is exact: organizations without dependency inventories spent weeks determining their exposure while those with structured inventories responded in hours. AIBOM is the mechanism that prevents that scenario for AI-specific supply chain vulnerabilities.

📋 1. What Is the OWASP AIBOM Generator? The 2026 State of the Tool

The OWASP AIBOM Generator is an open-source command-line tool and Hugging Face Space maintained by the OWASP GenAI Security Project that automates the generation of AI Bills of Materials in CycloneDX 1.6 JSON format. The tool accepts a Hugging Face model identifier (such as “google-bert/bert-base-uncased” or “meta-llama/Llama-4-Scout-17B”) as its primary input, extracts all available metadata from the model’s repository on Hugging Face — including the model card, configuration files, and repository metadata — and produces a standardized, machine-readable AI-SBOM document that inventories the model’s key characteristics, known dependencies, training data metadata, and governance attributes.

OWASP AIBOM Generator Definition (2026): An open-source Python command-line tool and Hugging Face Space that automates the generation of AI Bills of Materials in CycloneDX 1.6 JSON format for AI models hosted on Hugging Face. The tool extracts metadata, calculates a completeness score with recommendations, and produces a machine-readable AIBOM suitable for audit, regulatory submission, security scanning, and procurement due diligence. Importantly: the generator documents what you know about the model — it does not automatically discover information the model provider has not published. Think of it as producing a structured, auditable ingredient label from whatever documentation the model’s creator made available.

The December 2025 migration to the OWASP GenAI Security Project brought significant improvements alongside the name change. The current tool focuses on three core capabilities: automated metadata extraction from Hugging Face model repositories (model cards, configuration files, and repository data); CycloneDX 1.6 JSON output generation aligned with SPDX standards; and a completeness scoring system that calculates a score for the generated AIBOM and provides specific recommendations for fields that could not be automatically populated. The team is simultaneously developing the OWASP AIBOM Generation Handbook — a companion resource documenting field mappings, standards alignment, and recommended practices for applying AIBOMs across governance, compliance, and incident response workflows. Two access methods are available: a command-line interface via the GitHub repository (for production and CI/CD integration), and a Hugging Face Space at owasp-genai-aibom.org (for on-demand generation without local installation). Both produce identical CycloneDX 1.6 JSON output.

Understanding what the OWASP AIBOM Generator is — and what it is not — prevents the most common implementation failure mode. The generator is an automated documentation tool that extracts and structures what is publicly known about a model. It is not a security scanner that discovers vulnerabilities, not an audit tool that validates compliance claims, and not a system that generates information the model provider has not published. A model with a well-documented Hugging Face model card and complete configuration files will produce a higher-completeness AIBOM than a model whose creator published minimal documentation. The completeness score the tool produces tells you exactly which fields need manual input — and that gap list is itself valuable governance information about where your AI supply chain transparency has blind spots.

🛠️ 2. Step-by-Step: How to Use the OWASP AIBOM Generator

The five-step process below covers AIBOM generation using the command-line tool, which is the appropriate method for production use, CI/CD pipeline integration, and any context requiring automated, repeatable generation. For a quick one-off generation without installation, the Hugging Face Space at owasp-genai-aibom.org accepts a model identifier and produces the JSON output directly in the browser — useful for evaluation and demonstration but not for production workflows.

Step 1 — Installation and Prerequisites

The OWASP AIBOM Generator requires Python 3.8 or higher, pip, and Git. Before installing, verify your Python version with python3 --version. The tool is installed from the OWASP GenAI Security Project GitHub repository at github.com/GenAI-Security-Project/aibom-generator. Clone the repository using git clone https://github.com/GenAI-Security-Project/aibom-generator.git, navigate into the directory, and install the required Python dependencies using pip install -r requirements.txt. No API keys or authentication are required for publicly available Hugging Face models. For private or gated models on Hugging Face, you will need to authenticate using a Hugging Face token — set the HUGGINGFACE_TOKEN environment variable before running the tool. The Hugging Face Space interface (owasp-genai-aibom.org) requires no installation and no authentication for public models, making it the fastest option for teams evaluating the tool before committing to CLI deployment.

Before running your first generation, have the following information available: the exact Hugging Face model identifier (format: “organization/model-name” — for example “google/flan-t5-large” or “microsoft/phi-4”), your organization’s name (used to populate the --manufacturer field), an internal version identifier for the model deployment (used to populate --version), and any supplementary documentation about the model’s training data, intended use, or known limitations that you will want to add manually after the automated extraction. The tool will generate the AIBOM from whatever is publicly available on Hugging Face — your supplementary documentation addresses the completeness score gaps the tool will flag after generation.

Step 2 — Running the Generator and Inputting Model Information

The basic CLI command to generate an AIBOM is: python3 -m src.cli <model-identifier>. For example: python3 -m src.cli google-bert/bert-base-uncased generates a CycloneDX 1.6 JSON AIBOM for BERT-base-uncased and outputs it to the terminal. To add your organization’s context and write the output to a file, use the advanced command format: python3 -m src.cli <model-identifier> --name "Your Model Display Name" --version "1.0.0" --manufacturer "Your Organization Name" --output "model-aibom.json". The --name field is your internal display name for this model deployment (which may differ from the Hugging Face model name if you are using it under a specific internal designation). The --version field should reflect your deployment version tracking, not necessarily the upstream model’s version. The --manufacturer field is your organization’s name as the party deploying and taking responsibility for this model in your system context.

After the generator runs, it outputs the CycloneDX 1.6 JSON document and a completeness score — a percentage rating of how completely the AIBOM’s AI-relevant fields are populated, along with a list of recommendations for fields that could not be automatically extracted and require manual supplementation. A completeness score of 60–80% is typical for well-documented open-source models on Hugging Face; scores below 50% indicate significant documentation gaps that you will need to address through manual field population. Do not treat a low completeness score as a tool failure — it is accurate information about how much the model’s creator has published, and the gap list is your actionable workplan for improving the AIBOM before submission to auditors or regulators. The EU AI Act’s technical documentation requirements under Annex IV are more comprehensive than what most model cards currently document — expect to manually supplement several fields for any AI system used in a high-risk context.

Step 3 — Configuring the Output Format

The OWASP AIBOM Generator produces CycloneDX 1.6 JSON as its default and primary output format. CycloneDX JSON is the recommended format for the vast majority of enterprise use cases in 2026 for three reasons: it is the format with the broadest tooling support (Dependency-Track, Grype, OWASP’s own validation tools, and most SBOM management platforms all natively consume CycloneDX JSON); it is machine-readable in a format that security scanning pipelines can directly process; and it is the format that the OWASP AIBOM Generator’s completeness scoring and validation features are most fully implemented for. CycloneDX v1.7 — the latest specification version — adds Data Provenance and Citations, Intellectual Property Transparency, and extended License Details fields that are particularly relevant for AI systems. The OWASP AIBOM Generator currently targets CycloneDX 1.6, which is the stable production version; check the project’s GitHub for the current supported specification version before production deployment.

SPDX compatibility is relevant for organizations that have standardized on SPDX for traditional software SBOMs and want to maintain format consistency across their full software and AI inventory. The OWASP GenAI Security Project’s documentation notes that the broader OWASP ecosystem supports SPDX as an alternative, and SPDX 3.0 added an AI Profile that covers AI-specific metadata fields. The practical guidance: if your organization already has an SBOM management platform and pipeline built around CycloneDX, use CycloneDX JSON for your AIBOM — the tooling ecosystem is the primary criterion, not the format specification itself. If your organization uses SPDX throughout and conversion adds friction, use the SPDX path. If you need to support both, tools like the CycloneDX CLI’s conversion functionality and cdxgen can translate between formats. For EU AI Act Annex IV compliance documentation submissions to national competent authorities, both CycloneDX and SPDX are acceptable — the requirement is structured documentation, not a specific format standard.

Step 4 — Reviewing and Validating the Generated AIBOM

After generation, the first step is reading the completeness score and the gap list carefully. The completeness score tells you what percentage of the AI-relevant CycloneDX fields were populated from the Hugging Face metadata; the gap list tells you exactly which fields were not populated and why. Work through the gap list systematically: some gaps can be addressed by adding supplementary metadata from the model’s paper, the provider’s website, or your own deployment documentation; others represent genuinely unknown information (training data details for closed proprietary models, for instance) that must be documented as “not available” or “undisclosed by provider” rather than left blank. An AIBOM with documented gaps is governance-compliant. An AIBOM with empty fields that the auditor expects to see populated is not.

To validate the JSON output against the CycloneDX specification before storage or submission, use the CycloneDX CLI validation tool: cdx-validate --input model-aibom.json. This checks the document against the CycloneDX JSON schema and reports any structural errors. Common validation errors include missing required fields (the bomFormat and specVersion header fields are required), invalid date formats (use ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ), and invalid enum values in fields like type (must be one of the CycloneDX-specified component type values). If validation passes, the document is structurally valid CycloneDX — which is the prerequisite for import into SBOM management platforms and security scanning tools. Structural validity does not mean compliance completeness; an AIBOM can be structurally valid with a low completeness score.

Step 5 — Storing and Sharing the AI-SBOM

Where you store the AIBOM and who has access to it determines its governance value. For organizations with an existing artifact repository (Nexus, JFrog Artifactory, GitHub Packages), the AIBOM JSON file should be stored as a versioned artifact tied to the specific model version it documents — the same way a software SBOM is stored alongside the software release it describes. OWASP Dependency-Track is the primary open-source platform for SBOM and AIBOM management — it imports CycloneDX JSON, maintains a version history, continuously monitors components against vulnerability databases, and generates policy violation alerts when new vulnerabilities affect inventoried components. For organizations with GRC platforms (ServiceNow, OneTrust, MetricStream), the AIBOM document should be linked to the AI system’s risk register entry and made accessible to auditors, compliance reviewers, and the AI governance team.

Regeneration frequency is a governance question, not a technical one. As a baseline: regenerate the AIBOM whenever the model version changes (even minor version updates), whenever the model’s deployment configuration changes (new tools, new data sources, changed system prompts), whenever a new version of the CycloneDX specification becomes the target standard, and at a minimum annually as part of your AI governance review cycle. For EU AI Act compliance, Article 11 requires that technical documentation be kept up to date — which means the AIBOM must reflect the current state of the system, not the state at initial deployment. Dynamic RAG systems that continuously ingest new documents are a special case: the model component of the AIBOM remains stable, but the data component changes with every ingestion cycle and should be tracked separately using your data governance tooling rather than through the AIBOM generator itself.

📄 3. What a Complete OWASP AIBOM Output Looks Like — Annotated Field Reference

No competitor article provides a field-by-field walkthrough of the CycloneDX AI-SBOM output. This section gives security teams, compliance officers, and auditors a practical reference for understanding every significant field in the generated document — what it documents, why it matters for governance and security, where the data comes from, and which fields EU AI Act Annex IV auditors focus on most intensively.

A CycloneDX AI-SBOM consists of two main sections: a document metadata envelope (covering the BOM document itself — its format, version, serial number, and generation timestamp) and a components array (covering the AI model component with all its AI-specific properties). The OWASP AIBOM Generator produces both, with the AI-specific fields nested under the component’s modelCard or equivalent CycloneDX ML-BOM properties. The table below annotates the fields that appear in the OWASP AIBOM Generator’s CycloneDX 1.6 output.

Field annotations based on CycloneDX 1.6 specification (cyclonedx.org), OWASP AIBOM Generator output structure (github.com/GenAI-Security-Project/aibom-generator), and EU AI Act Annex IV (applicable from August 2, 2026 for high-risk AI systems). Some field names may vary slightly between CycloneDX specification versions. Always validate against the current specification version at cyclonedx.org.

The four fields that EU AI Act auditors focus on most intensively in AIBOM reviews for high-risk systems are: the trainingDatasets field (Annex IV §2(d,e) — training data characteristics), the performanceMetrics field (Annex IV §2(g) — validation and testing results), the considerations/limitations field (Annex IV §1(c) — known limitations and foreseeable misuse), and the metadata.timestamp field (Article 11 currency requirement). These are the fields that auditors will probe most deeply and that require the most supplementary documentation beyond what the OWASP AIBOM Generator can extract automatically for most commercial models.

🔗 4. Integrating AIBOM Generation Into Your AI Development Workflow

AIBOM generation produces the greatest governance value when it is integrated into the AI development and deployment lifecycle as a mandatory, automated step — not run once and archived. Your AI risk register should include an AIBOM reference for every inventoried AI system, and that AIBOM should be regenerated whenever the system changes in ways that affect its risk profile. The timing question that most organizations get wrong is treating AIBOM generation as a deployment-gate activity when it should also be a model-selection activity. Before committing to a specific foundation model, running the OWASP AIBOM Generator against it gives you the completeness score immediately — which is a proxy for how much documentation exists, how well the training data is disclosed, and how transparent the model creator has been about limitations. A low completeness score at selection time signals a model that will be difficult to document for compliance purposes regardless of which tool you use.

For CI/CD pipeline integration, the CycloneDX Tool Center lists two directly relevant tools: AIBoMGen-cli (a Go CLI tool that scans repositories for Hugging Face model usage, generates CycloneDX AI BOMs, validates, checks completeness, enriches, and merges AIBOMs with SBOMs) and a GitHub Action that generates a CycloneDX AI BOM for Hugging Face models referenced in a repository using AIBoMGen-cli. The cdxgen tool (github.com/cdxgen/cdxgen) also supports AI-BOM generation and CI/CD integration — use --include-formulation --bom-audit-categories ai-bom to include AI-BOM workflow coverage for prompt files, AI services, MCP configs, and model metadata. OWASP Dependency-Track is the recommended management platform for consuming, storing, and continuously monitoring generated AIBOMs against vulnerability databases — it provides the inventory management layer that converts point-in-time generation into continuous governance. For organizations building on existing SBOM tooling, Syft (for software SBOM generation) and Grype (for vulnerability scanning) both integrate with the CycloneDX format and can be extended to include AIBOM artifacts in a unified supply chain security pipeline.

The 2026 AIBOM Workflow Standard: Generate an AIBOM at model selection (to assess documentation maturity before commitment), at initial deployment (as the baseline governance document), at every model version update (to track component changes), and at least annually (to maintain EU AI Act Article 11 currency). Store in your artifact repository alongside the model deployment artifact. Link to the AI risk register entry. Surface completeness gaps to the AI governance team as a standing action item. This is not theoretical — it is the workflow pattern that satisfies both NIST AI RMF Map function requirements and EU AI Act Annex IV obligations simultaneously.

The governance value of AIBOM generation extends well beyond compliance documentation. When connected to your AI risk register, the AIBOM transforms from a static document into a living component of your AI risk management infrastructure. Each field in the AIBOM maps to specific risk categories: the training data fields address data poisoning risk (OWASP LLM04); the license fields address supply chain IP risk (OWASP LLM03); the limitations and considerations fields address misinformation and overreliance risk (OWASP LLM09); the version fields address model-level vulnerability exposure and the ability to respond when new CVEs are disclosed. For organizations building NIST AI RMF-aligned governance programs, the AIBOM is the primary artifact produced by the Map function’s AI system inventory activities — and it feeds directly into the Measure function’s risk evaluation processes. Our guide to the NIST Cyber AI Profile (NIST IR 8596) covers how the AIBOM fits within the cybersecurity-specific AI governance controls that extend CSF 2.0 to AI systems.

⚠️ 5. OWASP AIBOM Generator — Common Issues and How to Fix Them

The troubleshooting scenarios below cover the most frequent issues security teams and compliance professionals encounter when using the OWASP AIBOM Generator in production. Each scenario includes the cause, diagnostic steps, and the recommended resolution.

Issue 1: Incomplete Model Documentation — Low Completeness Score. This is the most common situation encountered and is not a tool error — it is accurate information about the model’s documentation state. A low completeness score means the model’s creator did not publish the information needed to populate those fields on Hugging Face. The correct response is not to try to inflate the completeness score with placeholder data — that produces a misleading AIBOM. The correct response is to work through the gap list systematically: search the model’s research paper (most Hugging Face models link to an ArXiv paper with training methodology and dataset details); check the provider’s official documentation website; review the model’s GitHub repository for configuration files that document architecture details not reflected in the model card; and contact the provider directly for commercial models used in regulated contexts. Where information is genuinely not available — typically for proprietary commercial model training data — document this explicitly as “not disclosed by provider” in the relevant fields. A transparent AIBOM with documented gaps is more defensible to auditors than one where missing information has been papered over with vague entries.

Issue 2: CycloneDX Format Validation Errors. Validation errors from cdx-validate most commonly fall into three categories. Missing required header fields: if bomFormat or specVersion are absent from the generated document, this indicates a tool version issue — update to the latest OWASP AIBOM Generator version from the GitHub repository and regenerate. Invalid date format: all timestamps in CycloneDX must be ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) — if you have manually edited any timestamp fields, verify the format. Invalid enum values: fields like type and scope must use the exact string values specified in the CycloneDX schema — consult the CycloneDX v1.6 JSON reference at cyclonedx.org/docs/1.6/json/ for the complete list of valid values for each enum field.

Issue 3: Field Mapping for Proprietary Enterprise Models. If your organization is using a proprietary fine-tuned model that is not hosted on Hugging Face, the OWASP AIBOM Generator cannot automatically extract its metadata — the tool’s automated extraction is specifically designed for Hugging Face-hosted models. For proprietary models, use the generator’s manual input workflow: create a configuration file pre-populated with the fields you do know (name, version, manufacturer, intended purpose, deployment environment, known dependencies) and manually populate AI-specific fields from your internal model documentation. The CycloneDX schema reference provides the complete list of AI/ML-BOM fields and their data types. This manual approach is also appropriate for third-party API-accessed models (OpenAI, Anthropic, Google) where you are not hosting the model but need to document your integration with it for supply chain transparency — document what the provider has disclosed publicly and flag the rest as vendor-undisclosed.

Issue 4: Third-Party Fine-Tuned Models Where Base Model Information Is Unclear. This scenario arises when your organization has consumed a fine-tuned model where the fine-tuning organization has not clearly documented the base model used. The recommended approach is a two-component AIBOM structure: one component entry for the fine-tuned model (with the information the fine-tuner has disclosed) and a separate component entry for the base model (with whatever is publicly known about the base model from Hugging Face or the base model provider’s documentation), with the dependency relationship between them explicitly declared in the dependencies section of the CycloneDX document. This two-component approach is the CycloneDX-standard method for documenting derived and composed components, and it accurately represents the supply chain structure of a fine-tuned model deployment — which is important for security assessment because vulnerabilities or training data issues in the base model affect all fine-tuned derivatives.

🏁 6. Conclusion: AIBOM Generation as Operational AI Security Practice

The OWASP AIBOM Generator in 2026 represents the operational maturity that the AI supply chain transparency conversation has been building toward since the first CISA SBOM AI use cases were published. The tool is accessible — a Python CLI that runs against any Hugging Face model identifier and produces a valid CycloneDX 1.6 AIBOM in minutes. The standard it produces to is stable and adopted. The regulatory requirements it satisfies are in force. And the governance value it generates — AI system inventory, supply chain risk visibility, compliance evidence, incident response readiness — compounds significantly when AIBOM generation is integrated into the AI development lifecycle as a routine practice rather than a one-time compliance exercise.

The OWASP AIBOM Generation Handbook, currently in development alongside the tool, will provide the companion documentation layer that gives governance teams the field mappings, standards alignment detail, and recommended practices for applying AIBOMs across all workflow contexts. Until that resource is published, this guide, the CycloneDX specification at cyclonedx.org, and the OWASP GenAI Security Project’s GitHub repository provide the complete reference for production AIBOM generation. The organizations that build AIBOM generation into their AI governance programs now — before the EU AI Act’s enforcement mechanisms are fully operationalized and before enterprise procurement requirements become ubiquitous — are building the documentation infrastructure that will differentiate them from competitors who are still trying to reconstruct AI system transparency retroactively under regulatory pressure.

📌 Key Takeaways

🔗 Related Articles

• 📖 AI System Bill of Materials (AI-SBOM) Explained: How to Document AI Supply Chains
• 📖 OWASP Top 10 for LLMs Explained: All 10 Risks + Mitigation Checklist (2026)
• 📖 EU AI Act Explained: A Beginner-Friendly Compliance Guide + Practical Checklist
• 📖 AI Risk Assessment and Risk Register: How to Evaluate AI Use Cases Before You Deploy
• 📖 NIST Cyber AI Profile (NIST IR 8596) Explained: How to Use CSF 2.0 to Secure AI Systems