AI SBOM Compliance Guide

• 1: Program Foundation
• 1.1: 3.1 Policy
• 1.2: 3.2 Competence
• 1.3: 3.3 Awareness
• 1.4: 3.4 Program Scope
• 2: AI Extension Process
• 2.1: 3.5 License Obligations
• 2.2: 3.6 Transparency Obligations
• 2.3: 3.9 AI SBOM
• 3: Operations
• 3.1: 3.7 Access
• 3.2: 3.8 Effectively Resourced
• 4: Governance
• 4.1: 3.10 Governance
• 5: Tools
• 5.1: OWASP AIBOM Generator
• 5.2: cdxgen
• 5.3: Model and Container Scanners (Lab700x, Trivy, Syft)

1 - Program Foundation

This is stage 1 of the implementation roadmap. It defines the program’s scope (3.4), establishes policy (3.1), and secures the competency and awareness of participants (3.2, 3.3). All subsequent clauses operate on top of this foundation.

1.1 - 3.1 Policy

1. Clause Overview

Without an AI SBOM policy, an organization ends up deploying AI systems while developers remain unaware of the licensing obligations attached to models and datasets. In AI, what needs to be tracked goes beyond code. Model weights, training datasets, and the model tree derived from other models each carry their own license, and non-standard licenses that restrict the purpose of use — such as the Llama Community License or the RAIL family — are common. Missing these obligations leads to copyright disputes, violations of usage restrictions, and terminated business contracts.

To prevent this risk, 3.1 requires establishing a documented policy that governs AI SBOM compliance and communicating it so that program participants are aware of its existence. This policy must reflect business strategy, the legal requirements of relevant jurisdictions, and the level of risk appropriate to the use case. All subsequent clauses (competence, license obligations, AI SBOM, governance, and so on) operate on top of this policy.

2. Activities to Perform

• Draft and formalize a policy document that governs AI SBOM compliance.
• Define the scope of application in the policy (AI systems deployed externally, external models/datasets brought in, internal models released publicly, etc.).
• Reflect business strategy, the legal requirements of relevant jurisdictions, and the risk level for each use case in the policy.
• Include in the policy a list of licenses allowed or prohibited for models and datasets. ([Guide Recommendation] Because compliance with non-standard licenses is hard to track automatically after the fact, decide it through policy at intake time.)
• Establish and document a procedure for communicating the policy to program participants (development, legal, security, data staff, etc.).
• Retain records that prove the policy was communicated (training completion, notice history, etc.).
• Include in the policy a procedure for periodically reviewing it and re-communicating it when it changes.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.1.1 Documented AI SBOM Policy

How to Comply

The AI SBOM policy is a formal document that captures the principles and procedures by which the organization manages the licensing and transparency obligations of its AI systems. The policy should include its purpose, scope, roles and responsibilities, principles for reviewing model and dataset licenses, AI SBOM management, how transparency obligations are addressed, and the review cycle. Because this document itself is verification material 3.1.1, manage it as a formal document with recorded version and approval history.

For an organization that already has an ISO/IEC 5230 open source policy, it is more efficient to add an AI-related section to the existing policy than to create a separate new one. Add that models and datasets fall within the scope of license review, how non-standard licenses are handled, and what format is used to manage the AI SBOM.

A policy is not a document to be written once and left alone. Because the AI regulatory landscape changes quickly, conduct a periodic review at least once a year and record the change history.

Considerations

• State the AI-specific scope explicitly: Clearly state in the policy that license review covers not only code but also model weights, training/testing/validation datasets, and the derivation relationships in the model tree.
• Allowed/prohibited license lists: Divide model and dataset licenses into allowed and prohibited lists, based on whether commercial use is permitted and whether there are behavioral use restrictions, and set this in the policy in advance. ([Guide Recommendation])
• Approval procedure: Have the legal team or the AI governance lead give final approval, and record the approval date and approver.
• Version control: Maintain the document version and change history so that previous versions can be compared during an audit.
• Periodic review: Review at least once a year, and record the review completion date and reviewer.

Sample

Below is a sample of the scope of application and the allowed/prohibited license lists for an AI SBOM policy. This text becomes a core component of verification material 3.1.1. Check the actual terms of each license against its original text, then classify it to fit the organization’s use case.

## 1. Purpose and Scope

This policy defines the compliance principles and procedures for the company to
develop and deploy AI systems safely and responsibly. It is designed to satisfy
the requirements of ISO/IEC 5230 (open source license compliance) and the
OpenChain AI SBOM Compliance Guide.

Scope:
- All AI systems, models, and services distributed externally.
- Pre-trained models and datasets brought in from outside.
- Activities that release internal models to the outside.

## 2. Model/Dataset License Classification

Licenses for models and datasets being brought in are reviewed against the
classification below. A license not in this classification goes through review
by the AI governance lead before being brought in.

- Allowed (commercial use permitted, no behavioral restrictions): Apache-2.0, MIT, BSD, CC-BY-4.0, etc.
- Conditionally allowed (use after review): licenses with restrictions on purpose or
  scale of use, such as the Llama Community License, the Gemma Terms of Use,
  and the OpenRAIL family
- Prohibited (non-commercial only, etc.): using a CC-BY-NC dataset in a commercial product, etc.

3.1.2 Policy Awareness Procedure

How to Comply

Writing the policy document alone is not enough. A communication procedure must be established and documented so that program participants actually become aware the policy exists. This communication procedure document itself is verification material 3.1.2. Because AI systems involve not just developers but also data staff, legal, and security, design the channel so the policy reaches all of them.

Include AI SBOM policy guidance in onboarding for new hires, and use internal wiki postings and email notices for existing employees. To prove that the policy was communicated, retain evidence such as notice history and training completion records for at least three years.

Considerations

• Use multiple channels: Use two or more channels, such as an internal wiki, email notices, and onboarding training.
• Include AI-related roles: Include dataset owners and model operators as recipients as well.
• When the policy changes: Have a separate procedure to notify participants of changes immediately.
• Retain evidence: Keep notice history and training completion certificates for at least three years.

Sample

Below is a sample policy communication notice email. Retaining the send history serves as evidence for verification material 3.1.2.

Subject: [AI Compliance] AI SBOM Policy Notice and Acknowledgment Request

To: Employees involved in AI system development, operations, and data
From: AI Compliance Officer

Hello,

Our AI SBOM compliance policy has been established (or revised).
All employees involved in using, bringing in, or deploying AI models and
datasets are asked to review and familiarize themselves with the policy
document below.

- Policy document: [internal portal link]
- Key contents: model/dataset license classification, license obligation
             review procedure, AI SBOM management, transparency obligation response
- Policy version: v1.0 (effective date: YYYY-MM-DD)

Contact: AI Compliance Officer (ai-compliance@company.com)

5. References

• License obligation review procedure: 3.5 License Obligations
• Basic structure of an open source policy: ISO/IEC 5230 Compliance Guide — 3.1.1 Policy
• AI license management strategy: Enterprise Open Source Management Guide — AI Compliance

1.2 - 3.2 Competence

1. Clause Overview

If policy (3.1) defines what must be done, competence ensures there are people who can do it. AI SBOM compliance demands broader knowledge than open source compliance, which dealt only with code licensing. It requires judgment on the licensing of model weights and datasets, interpreting model cards, emerging AI regulation, and the usage restrictions of non-standard licenses.

3.2 requires identifying the roles and responsibilities that affect the program’s performance, determining the competence each role needs, and ensuring participants have it. The specification specifies competence in governance, security, safety, privacy, development, and supplier management functions where relevant to the use case.

2. Activities to Perform

• Identify and document the roles that affect the program’s performance and their responsibilities.
• Define the competence required for each role (governance, security, safety, privacy, development, supplier management).
• Add AI-specific competence (model/dataset licensing, model card interpretation, AI regulation) to the role-level competence definitions.
• Ensure participants are competent on the basis of education, training, and experience.
• Retain competence assessment evidence, and periodically check that the list stays up to date.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.2.1 List of Roles and Responsibilities

How to Comply

Document the roles involved in the program and the responsibilities of each. In addition to the usual open source roles, an AI SBOM program includes an AI governance role and roles that review models and datasets. Writing responsibilities out specifically makes the later work of defining competence (3.2.2) and assigning accountability (3.8.4) clearer.

Sample

| Role | Responsibility |
|------|------|
| AI Governance Lead | Approves the framework, determines regulatory obligations, chairs periodic reviews |
| AI SBOM Verification Owner | Generates, reviews, and approves the AI SBOM; reflects inbound materials |
| License Review Owner | Determines licensing obligations for models, datasets, and the model tree |
| Data Owner | Manages the provenance and licensing of training/validation datasets |

3.2.2 Competence Required per Role

How to Comply

Define the competence each role must have. Of the six functions the specification lists (governance, security, safety, privacy, development, supplier management), select the ones that apply to the role and use case, and add AI-specific competence. For example, the license review owner needs the competence to interpret the usage restrictions of non-standard licenses (Llama Community, OpenRAIL).

Sample

| Role | Required Competence |
|------|----------|
| AI Governance Lead | Governance, understanding of AI regulation (EU AI Act, Korea's AI Basic Act), risk management |
| AI SBOM Verification Owner | Development, SPDX/CycloneDX formats, model card interpretation, generation tool operation |
| License Review Owner | Supplier management, interpreting open source and non-standard licenses, model tree tracing |
| Data Owner | Privacy, dataset licensing, provenance management |

3.2.3 Competence Assessment Evidence

How to Comply

Assess whether each participant actually has the competence their role requires, and retain the evidence. Training completion, qualifications, and hands-on experience serve as the basis. Since AI regulation and licensing change quickly, periodically check the list to keep it current.

Considerations

• Diversify the basis for assessment: Use not only training completion but also practical work products (e.g., license review records) as competence evidence.
• Periodic checks: Re-review competence requirements when new regulation takes effect or new license types emerge.
• Fill gaps: When an assessment reveals a competence gap, close it with training or outside expertise (3.8 Effectively Resourced).

Sample (Competence Assessment Log)

| Participant (Role) | Role | Assessment Item | Basis | Result | Assessment Date |
|-------------|------|----------|----------|------|--------|
| Lee, OO | AI SBOM Verification Owner | Writing CycloneDX ML-BOM | Internal training + work products | Met | 2026-03-10 |
| Park, OO | License Review Owner | Interpreting non-standard licenses | 5 years of OSS legal experience | Met | 2026-03-10 |

5. References

• Procedure for attaching resources to roles: 3.8 Effectively Resourced
• Securing participant awareness: 3.3 Awareness
• ISO/IEC 5230 competence model: ISO/IEC 5230 Compliance Guide — 3.1.2 Competence

1.3 - 3.3 Awareness

1. Clause Overview

If competence (3.2) addresses “can they do it,” awareness addresses “do they know why they should.” It is not enough for participants to merely know that a policy exists. Compliance functions in practice only when participants also know how their own work contributes to the program and what happens if they fail to follow it.

3.3 requires ensuring that program participants are aware of four things: the AI SBOM policy, relevant business objectives, their own contribution to the program’s effectiveness, and the implications of not following the program’s requirements. In AI, the implications of non-conformance extend beyond copyright disputes to regulatory violations and breaches of usage restrictions, so participants must clearly recognize this.

2. Required Activities

• Ensure participants know the AI SBOM policy and where to find it.
• Communicate relevant business objectives (building trust, regulatory compliance, meeting supply-chain requirements).
• Inform participants how their own work contributes to the program.
• Inform participants of the implications of non-conformance (regulatory violations, contract termination, breaches of usage restrictions).
• Assess participants’ awareness and preserve evidence of that assessment.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.3.1 Evidence of assessed participant awareness

Compliance Method

Assess whether participants actually understand the four awareness elements and keep evidence of that assessment. If policy dissemination (3.1.2) proves that participants “were informed,” the awareness assessment proves that they “understood.” Assess through post-training comprehension quizzes, acknowledgment signatures, or interviews. Make sure the assessment does not omit the three elements the standard specifies in its verification material: the program’s objectives, one’s own contribution, and the implications of non-conformance.

Considerations

• Cover all four elements: In addition to policy awareness, include objectives, contribution, and the implications of non-conformance in the assessment. Omitting even one can be flagged during a certification audit.
• Emphasize AI-specific implications: Include regulatory violations (the EU Artificial Intelligence Act, Korea’s AI Basic Act) and breaches of non-standard license usage restrictions among the implications of non-conformance.
• Differentiate by role: Data staff and developers contribute differently, so tailor the assessment content to each role.
• Retain evidence: Preserve assessment results and acknowledgment signatures for use as verification material.

Sample (Awareness Assessment Log)

| Participant (Role) | Policy Awareness | Objectives Awareness | Contribution Awareness | Non-conformance Awareness | Assessment Method | Assessment Date |
|-------------|:--------:|:--------:|:--------:|:---------------:|----------|--------|
| Lee OO (Development) | Met | Met | Met | Met | Post-training check | 2026-03-10 |
| Park OO (Data) | Met | Met | Met | Met | Interview + signature | 2026-03-11 |

Sample acknowledgment signature form:

I have been informed of and understand our company's AI SBOM compliance policy, the program's
objectives, my own contribution, and the implications of non-conformance (regulatory violations,
license usage restriction breaches, contract termination).

Name: ____  Role: ____  Signature: ____  Date: ____

5. See Also

• Policy and dissemination procedure: 3.1 Policy
• Competence by role: 3.2 Competence
• ISO/IEC 5230 awareness example: ISO/IEC 5230 Compliance Guide — 3.1.3 Awareness

1.4 - 3.4 Program Scope

1. Clause Overview

Program scope determines how far compliance extends. If the scope is ambiguous, it becomes unclear which AI systems need an SBOM and which models’ licenses need review. Scope must be declared first so that every subsequent clause knows what it applies to.

3.4 requires declaring the scope of application for each program. Scope can differ by organization. Some organizations cover a single product line; others cover an entire department or the whole organization. In AI, scope determination covers not only self-developed models but also externally sourced models and datasets, and the external release of in-house models.

2. Required Activities

• Define what the program applies to (externally deployed AI systems, externally sourced models and datasets, external release of in-house models, and so on).
• Record what is excluded from application and the rationale for the exclusion.
• Keep the scope statement consistent with the scope of application in the policy document.
• Review and update the scope periodically as the business environment changes.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.4.1 Program scope statement

Compliance Method

State the program’s scope and limits in writing. Clearly note what is included, what is excluded, and if excluded, on what grounds. An AI SBOM program becomes clearer when it declares what it applies to by breaking it down into material types and activities. The table below is an example of organizing scope.

Table 1. Example of an AI SBOM program scope declaration

Considerations

• Consistency with policy: The scope statement should not conflict with the scope of application in 3.1 Policy.
• Grounds for exclusion: Record the rationale for excluded items. Even an internal experimental model falls into scope once it moves to external deployment, so put a review procedure in place for that transition point. ([Recommendation of this guide])
• Periodic review: Update the scope whenever a new product line or new AI service is introduced.

Sample (Scope Statement)

## AI SBOM Compliance Program Scope

### Applies To
This program applies to all AI systems, models, and services that the company deploys
externally, and to pretrained models and datasets sourced externally. It also covers
activities that release in-house models externally.

### Excluded
Models used solely for internal experimentation or research and not deployed externally
are excluded. However, if such a model transitions to external deployment, it is brought
into scope through the intake review procedure.

### Review Cycle
Scope is reviewed and updated at least once a year, or as the business environment
changes.

5. See Also

• Scope of application in the policy: 3.1 Policy
• AI SBOM for material within scope: 3.9 AI SBOM
• ISO/IEC 5230 scope example: ISO/IEC 5230 Compliance Guide — 3.1.4 Program Scope

2 - AI Extension Process

This is stage 2 of the implementation roadmap. It is the area where the AI SBOM guide extends most significantly beyond ISO/IEC 5230, covering licensing obligations (3.5), transparency obligations (3.6), and AI SBOM generation and management (3.9).

2.1 - 3.5 License Obligations

1. Clause Overview

License obligations are where the AI SBOM Guide expands most on ISO/IEC 5230. Where traditional open source compliance reviewed the licenses of code, AI expands the review to four fronts: an AI system’s code, model weights, datasets (including training, testing, and validation datasets), and the license of the AI system itself. It is common for a model to be derived from several other models, so each parent model sitting in the Model Tree can carry its own distinct license.

3.5 requires a procedure for reviewing these licenses to determine, in light of the AI system’s intended use, the obligations, restrictions, and rights each license grants. The review covers both obligations inherited from upstream and obligations passed downstream.

2. Activities to Perform

• Establish a procedure for identifying the licenses of code, weights, datasets, and the AI system itself.
• Track the license of each parent model in the model tree, and document the obligations, restrictions, and rights of each license.
• Perform an initial identification pass on source code and dependencies with automated scanning tools. ([Guide Recommendation])
• Route model weights, datasets, and non-standard licenses to legal or governance review. ([Guide Recommendation])
• Set up an intake procedure that requires license metadata to accompany any model or dataset brought in from outside. ([Guide Recommendation])
• Record the review results (obligations, restrictions, rights) in the AI SBOM for tracking.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.5.1 License Obligation Review and Documentation Procedure

How to Comply

Design the review procedure around the premise that the level of automation differs by material type. Source code and dependency licenses can be identified to a large degree with automated scanning tools such as FOSSology, ScanCode, and the OSS Review Toolkit. But the licensing of model weights and datasets, and the derivation relationships in the model tree, fall outside the reach of these tools or are identified with low accuracy. The usage-purpose restrictions of non-standard licenses require human interpretation. A realistic division of labor is therefore to do an initial identification pass with automated scanning, and route models, datasets, and non-standard licenses to legal or governance review.

The figure below shows the decision flow for determining license obligations as materials come in.

Figure 1. Decision flow for license obligation review

Considerations

• Enforce metadata at the intake gate: The largest cause of missed license obligations is license drift — the loss of provenance and license information as a model propagates downstream. One study reports that a substantial share of restriction clauses disappear in the transition from model to application (arXiv:2509.09873). Rather than trying to reconstruct this downstream, it is more effective to block the intake of materials lacking license metadata at the internal model/dataset registry. ([Guide Recommendation])
• Decide non-standard licenses through policy in advance: The behavioral use restrictions of the Llama Community License or the OpenRAIL family are hard to track automatically for compliance after the fact. Decide them at intake time using the allowed/prohibited lists in 3.1 Policy. ([Guide Recommendation])
• Trace the model tree: Check the model card to see which parent model an incoming model was derived from, and review whether the parent model’s license obligations propagate downstream.
• Check dataset usage restrictions: Check whether a non-commercial-licensed dataset such as CC-BY-NC was used to train a commercial product. Dataset license omissions and misstatements are common, so cross-check against the original text.
• Recognize the limits of automation: Do not treat automated scan results as the final judgment. Tools help with identification; people handle the interpretation of obligations and conflict determination.

Sample

Below is a sample of the core part of a license obligation review procedure document. This procedure document becomes verification material 3.5.1.

## AI License Obligation Review Procedure

### 1. Scope of Review
- AI system code and dependencies
- Model weights (imported models, fine-tuned models)
- Datasets (training, testing, validation)
- Licenses of parent models in the model tree

### 2. Review Steps
1) Automated identification: scan code and dependencies for licenses using an SCA tool.
2) Metadata collection: collect licenses for models and datasets from model cards and
   datasheets. Hold intake if metadata is missing.
3) Classification: check identified licenses against the policy's allowed/conditional/
   prohibited lists.
4) Legal review: route non-standard or unclear licenses to legal/governance review to
   interpret the obligations.
5) Recording: record upstream and downstream obligations, restrictions, and rights in
   the AI SBOM.

### 3. Responsibility and Frequency
- Initial identification: development staff
- Interpreting obligations: legal / AI governance lead
- Re-review: when a model or dataset is replaced, and at least once a quarter

5. References

• Policy for allowed/prohibited license lists: 3.1 Policy
• AI SBOM for recording review results: 3.9 AI SBOM
• Automated scanning tools: Tools — FOSSology, SCANOSS
• AI model/dataset licensing strategy: Enterprise Open Source Management Guide — AI Compliance

2.2 - 3.6 Transparency Obligations

1. Clause Overview

If license obligations (3.5) ask “do we have the right to use this material,” transparency obligations ask “what must we disclose about this material.” The two obligations come from different sources. License obligations are imposed by the rights holder through a contract; transparency obligations are imposed by regulation through law.

3.6 requires having a procedure to review whether there are transparency obligations imposed by regulation. The scope of review includes training, testing, and verification datasets, taking into account the model’s intended use. If the use case for the training data creates a transparency issue (e.g., a disclosure obligation to downstream recipients), appropriate risk mitigation measures must be taken. As the EU Artificial Intelligence Act begins full enforcement of transparency obligations from August 2026, the practical weight of this clause is growing.

2. Required Activities

• Maintain a procedure to identify the transparency regulations that apply to AI systems being adopted or developed.
• Review whether training, testing, and verification datasets carry disclosure obligations, based on their intended use.
• Determine risk mitigation measures where a disclosure obligation to downstream recipients exists.
• Document the transparency measures taken.
• Regularly update and reflect the latest transparency obligations set by regulators. ([Recommendation of this guide])

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.6.1 Procedure to review and document transparency obligations

Compliance Method

Transparency obligations differ by regulation, so first identify which regulations apply. Once the applicable regulations are determined, derive the disclosure items each one requires and reflect those items in the AI SBOM or model card. Unlike license obligations, transparency obligations center on “disclosure,” so the output must be organized in a form that can be delivered externally.

The table below lists the main transparency obligations that intersect with the AI SBOM. The regulatory timeline and broader context are managed together in the regulatory matrix in 3.10 Governance.

Table 1. Transparency obligations that intersect with the AI SBOM (as of June 2026)

The figure below shows the review flow that derives transparency obligations from a material’s intended use.

Figure 1. Transparency obligation review flow

Considerations

• Dataset provenance is central: Most transparency obligations attach to training data. A dataset’s provenance and license must be recorded in the AI SBOM to fulfill disclosure obligations. This connects directly to the AI SBOM (3.9).
• Intended use is the criterion: The same model can carry different transparency obligations depending on the use case. High-risk uses or services aimed at the general public carry heavier obligations.
• Downstream disclosure obligations: When supplying a model or system externally, review what information the recipient must be told. Risk mitigation can be fulfilled through a public summary of training data or contractual notice.
• Reflect regulatory change: Since the EU Artificial Intelligence Act applies transparency obligations from August 2026, update the procedure to match the timeline. Responsibility for the update is managed by governance (3.10).

Sample (Transparency Obligation Review Procedure)

Below is a sample of the core part of a transparency obligation review procedure document. This procedure document becomes verification material 3.6.1.

## Transparency Obligation Review Procedure

### 1. Identify Applicable Regulations
Identify applicable regulations based on the AI system's intended use and deployment
region.
(e.g., EU market deployment → EU Artificial Intelligence Act; domestic high-impact AI →
Korea's AI Basic Act)

### 2. Derive Disclosure Items
Organize each regulation's transparency obligations into disclosure items.
- Training data summary (EU Artificial Intelligence Act Article 53)
- AI-generated / interaction labeling (EU Artificial Intelligence Act Article 50, Korea's
  AI Basic Act)
- Data provenance disclosure (Korea's AI Basic Act)

### 3. Downstream Review
Review the information to be conveyed to recipients on external supply, and determine the
necessary risk mitigation measures.

### 4. Reflection and Documentation
Reflect the derived disclosure items in the AI SBOM and model card, and record the
measures taken.

### 5. Responsibility and Cycle
- Review: Legal and AI governance lead
- Update: On changes to regulatory enforcement timelines, and at least semiannually

5. See Also

• Distinction from license obligations: 3.5 License Obligations
• AI SBOM to hold disclosure items: 3.9 AI SBOM
• Regulatory timeline and governance: 3.10 Governance
• AI model licenses and labeling obligations: Enterprise Open Source Management Guide — AI Compliance

2.3 - 3.9 AI SBOM

1. Clause Overview

An AI SBOM (AI System Bill of Materials) is a list capturing the elements that make up an AI system and the information about them. Where a traditional SBOM records software components, an AI SBOM adds models, weights, datasets, and hyperparameters on top. 3.9 requires a procedure for generating and managing the AI SBOM.

The format is left open. The specification states that SPDX, CycloneDX, or any other format is acceptable. There is, however, one obligation: the AI SBOM shall account for inbound materials from third parties. If pre-trained models and datasets brought in from outside are left out, the basis for tracking license obligations (3.5) and transparency obligations disappears.

The AI SBOM area is where the line “generation is automated by tools, but accuracy and compliance judgment are filled by people” is sharpest. This page walks through the procedure along that line.

2. Activities to Perform

• Establish a procedure for identifying, tracking, reviewing, approving, and archiving the components of an AI system (models, datasets, etc.).
• Decide on an AI SBOM format (SPDX 3.0 AI Profile or CycloneDX ML-BOM recommended). ([Guide Recommendation])
• Ensure models and datasets brought in from third parties are always included in the AI SBOM.
• Wire a generation tool into CI/CD to regenerate the AI SBOM repeatedly. ([Guide Recommendation])
• Have a person review whether the license and provenance fields of the generated AI SBOM are accurate. ([Guide Recommendation])
• Retain records (generation history, approval history) demonstrating that the procedure was followed.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.9.1 AI SBOM Management Procedure (Identification, Tracking, Review, Approval, Archiving)

How to Comply

Design the AI SBOM procedure around four stages: generation, review, approval, and archiving. Automate the generation stage with tools, and leave the review and approval stages to people. Even when a tool copies a license field straight from a model card, it cannot judge whether that license actually fits the use case, or whether something is missing or misstated.

The figure below shows the flow from AI SBOM generation to archiving.

Figure 1. Procedure from AI SBOM generation to archiving

Tool Mapping

Below are open source tools usable at each stage. “Automation level” indicates how far a tool handles that task on its own.

Installation, usage, and execution screens for each tool are covered in detail in the Tools section (OWASP AIBOM Generator, cdxgen, Model/Container Scanners).

The command to generate an AI BOM with cdxgen is as follows. You can pass a Hugging Face model URL and purl, a Modelfile, or a GGUF artifact directly (cdxgen AI-BOM docs).

# Generate an AI BOM from the AI project directory
cdxgen -t ai -o aibom.json .

# Generate including AI/ML metadata (formulation)
cdxgen -t ai --include-formulation -o aibom.json .

The OWASP AIBOM Generator takes a Hugging Face model as input, builds a CycloneDX-format AIBOM, and scores its completeness. It is maintained by the OWASP Gen AI Security Project and is also available as a Hugging Face Space (OWASP AIBOM Generator).

Hands-On — Generating with cdxgen

This is the result of actually running cdxgen against a summarization app (depending on transformers and torch) that loads a pre-trained model (facebook/bart-large-cnn). The tool automatically identifies 5 dependencies and produces a CycloneDX 1.7-format BOM.

$ cdxgen -t python --include-formulation -o aibom.json .
CycloneDX Generator 12.5.1 (Node.js)

Generated components — 5 items (CycloneDX 1.7):
  transformers     4.44.2    pkg:pypi/transformers@4.44.2      license: empty
  torch            2.4.0     pkg:pypi/torch@2.4.0             license: empty
  numpy            1.26.4    pkg:pypi/numpy@1.26.4            license: empty
  tokenizers       0.19.1    pkg:pypi/tokenizers@0.19.1       license: empty
  huggingface-hub  0.24.6    pkg:pypi/huggingface-hub@0.24.6   license: empty

One component from the generated BOM looks like this. The identification evidence is filled in, but the licenses field is empty.

{
  "name": "transformers",
  "version": "4.44.2",
  "purl": "pkg:pypi/transformers@4.44.2",
  "type": "library",
  "evidence": {
    "identity": [
      { "field": "purl", "confidence": 0.5,
        "methods": [{ "technique": "manifest-analysis", "value": "requirements.txt" }] }
    ]
  }
}

Figure 2. cdxgen 12.5.1 execution output (run on 2026-06-13, -t python --include-formulation)

Format Sample (CycloneDX ML-BOM)

Below is a shortened example of the model component structure in a CycloneDX 1.6 ML-BOM. The key structure follows the machine-learning-model component and modelCard in the official CycloneDX spec. If the license is non-standard (has no SPDX ID), state it with name.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "bom-ref": "model-llama31-8b",
      "type": "machine-learning-model",
      "group": "meta-llama",
      "name": "Llama-3.1-8B",
      "version": "1.0",
      "licenses": [
        { "license": { "name": "Llama 3.1 Community License" } }
      ],
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "architectureFamily": "llama",
          "datasets": [
            { "type": "dataset", "name": "Public pretraining corpus", "classification": "public" }
          ]
        },
        "considerations": {
          "useCases": ["Internal document summarization"],
          "technicalLimitations": ["Potential for hallucination", "Performance variance in Korean"]
        }
      }
    }
  ]
}

If you use SPDX 3.0, the AI Profile and Dataset Profile express the same information (SPDX 3.0 AI Profile). The concrete fields of each format and the technical details of generation tools are covered in the ISO/IEC 42001 Guide — AI SBOM.

Considerations

• Reflect inbound materials (specification obligation): Set up a procedure that generates an SBOM entry at intake time so that models and datasets brought in from outside are never missing from the AI SBOM. This is a shall-level obligation.
• Generation by tool, review by people: Generation tools copy the license written on the model card as-is. Because model cards themselves commonly have missing or incorrect license information, have a person check the license and provenance fields of the generated AI SBOM against the original source.
• Format consistency: Pick either SPDX or CycloneDX as the organization’s default format and operate tools and repositories around it consistently. Both formats treat models and datasets as first-class components.
• CI/CD integration: The AI SBOM is not a one-time deliverable. Wire it into the pipeline so it is regenerated whenever a model or dataset changes.

3.9.2 Records Demonstrating Procedure Compliance

How to Comply

Verification material 3.9.2 is the record showing the procedure was actually followed. Alongside the AI SBOM file itself, keep a history of who generated, reviewed, and approved it and when. If it is generated automatically in CI/CD, the build logs and the generated SBOM artifact become the record, and the upload history to a management tool such as Dependency-Track also serves as evidence.

Considerations

• Retain generation history: Keep the AI SBOM from each point in time for every version of the supplied AI system to maintain traceability.
• Approval record: Record who reviewed and approved it. This connects to the lifecycle review in Governance (3.10).

5. References

• License obligation review procedure: 3.5 License Obligations
• Technical details of AI SBOM formats and generation tools: ISO/IEC 42001 Guide — AI SBOM
• SBOM management tools: Dependency-Track, cdxgen + Dependency-Track integration
• Governance and lifecycle review: 3.10 Governance

3 - Operations

This is stage 3 of the implementation roadmap. It establishes a channel to respond to external AI SBOM compliance inquiries (3.7) and assigns responsibility, personnel, and funding to the program (3.8).

3.1 - 3.7 Access

1. Clause Overview

Organizations that exchange AI systems in the supply chain need to verify each other’s compliance. That requires a publicly available channel for external inquiries, and readiness on the organization’s side to respond to them. Access secures both directions.

3.7 requires two things: publicly identifying a means by which a third party can make an AI SBOM compliance inquiry, and maintaining an internal procedure to respond effectively to that inquiry. In AI, AI-specific information — model and dataset licenses, training data provenance, model cards — is added to the subject matter of such inquiries.

2. Required Activities

• Publicly identify a means (e.g., a public email address) by which a third party can make an AI SBOM compliance inquiry.
• Post the public means somewhere externally discoverable, such as a product notice or website.
• Document the internal procedure for receiving, classifying, and responding to external inquiries.
• Define the responsible party and the response deadline.
• Record the history of inquiries and responses.

3. Requirements and Verification Material

4. Compliance Methods and Samples by Verification Material

3.7.1 Publicly identified means of external inquiry

Compliance Method

Identify a public contact means that anyone can find. A role-based email address (a job function address, not an individual) is stable. Post it in locations such as the product notice, the open source/AI policy page on the company website, or the contact field of the model card. Stating a response deadline alongside it builds trust.

Sample

AI Compliance Inquiries: ai-compliance@company.com

We accept inquiries regarding the components of the AI systems we provide, model and
dataset licenses, and AI SBOMs. We send an initial reply within 14 business days of
receipt.

(Posted at: product notice, company website AI policy page, model card contact field)

3.7.2 Internal inquiry response procedure

Compliance Method

Document the internal procedure from receiving an external inquiry to answering it. Define the stages of intake, classification, assignment, review, reply, and recording, with a deadline for each stage. Because AI SBOM inquiries need to reference model cards or license review records, the AI SBOM verification lead and the license review lead respond together.

The figure below shows the external inquiry response flow.

Figure 1. External AI SBOM compliance inquiry response flow

Considerations

• Set deadlines: Define both an initial reply deadline (e.g., 14 days) and a final answer deadline (e.g., 60 days).
• Protect AI-specific information: Set a standard for how far to disclose sensitive information such as model weights or training data when answering inquiries. Define the boundary between trade secrets and transparency obligations (3.6). ([Recommendation of this guide])
• Retain history: Record the inquiry content, the reply, and the processing time as verification material.

Sample (Response Procedure Outline)

## AI SBOM Compliance Inquiry Response Procedure

1. Intake: Register inquiries received at ai-compliance@.
2. Classification: Classify as AI SBOM request / license inquiry / transparency
   obligation inquiry.
3. Assignment: Assign to the AI SBOM verification lead or the license review lead based
   on classification.
4. Review and Reply: Reply after checking the relevant AI SBOM and model card. Follow the
   disclosure standard for sensitive information. Involve legal review if needed.
5. Record: Retain the inquiry, reply, and processing time.

Deadlines: 14 days for the initial reply, 60 days for the final answer.

5. See Also

• Role and resources of the response lead: 3.8 Effective Resource Allocation
• AI SBOM used in replies: 3.9 AI SBOM
• Disclosure scope and transparency obligations: 3.6 Transparency Obligations
• ISO/IEC 5230 external inquiry example: ISO/IEC 5230 Compliance Guide — 3.2.1 Responding to External Inquiries

3.2 - 3.8 Effectively Resourced

1. Clause Overview

If competence (3.2) defines who should be able to do what, effective resourcing is what actually attaches people, time, and budget to those roles so the program runs. When policy and procedures exist only on paper and no resources back them, compliance is a name only.

3.8 requires assigning accountability for program tasks and allocating adequate resources. There are five verification materials, covering the naming of role holders, the provision of staffing and funding, access to legal expertise, an internal responsibility-assignment procedure, and a non-conformance remediation procedure. The specification references the resource-related sections of ISO/IEC 42001 Annex B (B.4.2, B.4.6) and the human oversight determination section (B.9.3).

2. Activities to Perform

• Assign accountability for the successful execution of program tasks.
• Allocate sufficient time and funding to the tasks.
• Make legal expertise on AI SBOM compliance accessible to those who need it.
• Have a procedure for reviewing and updating the policy and its supporting tasks.
• Have a procedure for reviewing and remediating non-conformances.

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.8.1 Document Identifying Role Holders

How to Comply

Document, by name, the people, groups, or functions holding program roles. Including the job title alongside the name is more stable against personnel changes. The AI SBOM program needs, in addition to the usual open source roles, an AI governance lead, an AI SBOM verification owner, and a model/dataset license review owner.

Sample

| Role | Holder (Job Title) | Contact |
|------|-------------|--------|
| AI Governance Lead | Kim, OO (AI Ethics & Governance Lead) | ai-gov@company.com |
| AI SBOM Verification Owner | Lee, OO (Platform Engineer) | sbom@company.com |
| License Review Owner | Park, OO (Open Source Legal) | oss-legal@company.com |
| Security Owner | Choi, OO (Product Security) | psirt@company.com |

3.8.2 Staffing and Funding

How to Comply

Show that identified roles are actually staffed and that budget has been allocated. Record the time allocation (e.g., 30%) and the basis for the annual budget. AI SBOM compliance takes time for model/dataset review and tool operation, so estimate the per-role time allocation realistically.

Considerations

• State the time allocation: For a shared role, record the percentage of time allocated to AI SBOM work.
• Tool budget: Include the cost of AI SBOM generation/management tools and legal counsel in the budget.

Sample

| Role | Holder | Time Allocation | Annual Budget Basis | Approver / Approval Date |
|------|--------|----------|---------------|--------------|
| AI Governance Lead | Kim, OO | 30% | Personnel cost + regulatory counsel | CTO / 2026-01-15 |
| AI SBOM Verification Owner | Lee, OO | 50% | Personnel cost + tool operation | CTO / 2026-01-15 |

3.8.3 Access to Legal Expertise

How to Comply

Make legal expertise on AI SBOM compliance accessible to those who need it. Because interpreting non-standard licenses and determining regulatory obligations is legal’s job, specify the access path — internal legal counsel or an outside firm. Also define escalation criteria (which matters get escalated to legal).

Sample

- Internal: Open Source Legal Owner (Park, OO) — first-pass license review
- External: XX Law Firm, AI/IP team — non-standard license disputes, regulatory interpretation
- Escalation criteria: a license not on the policy's prohibited/conditional lists, determining
  downstream disclosure obligations, matters where new regulation newly applies

3.8.4 Internal Responsibility Assignment Procedure

How to Comply

Document the procedure for assigning internal responsibility for AI SBOM compliance. Vague responsibility leads to gaps, so a RACI matrix distinguishing Responsible (R), Accountable (A), Consulted (C), and Informed (I) per task is effective.

Sample (RACI Matrix)

R Responsible, A Accountable, C Consulted, I Informed

3.8.5 Non-Conformance Review and Remediation Procedure

How to Comply

Have a procedure for reviewing and remediating non-conformances (e.g., a prohibited-license model brought in, a missing AI SBOM, a failure to meet transparency obligations). Vary the handling deadline by severity. In AI, a licensing problem sometimes surfaces after a model has already been deployed, so prepare a remediation path that includes recall or replacement.

Sample (Remediation Procedure and Severity Criteria)

Remediation procedure: identify/report → assess severity → root-cause analysis → corrective
action → recurrence prevention → record

| Severity | Example | Handling Deadline |
|--------|------|----------|
| High | A prohibited-license model is included in a product shipped externally | Immediate response (contain/replace review within 48 hours) |
| Medium | An inbound model is missing from the AI SBOM | Backfill within 7 days |
| Low | Some model card metadata is missing | Handle at the next periodic review |

5. References

• Competence definitions per role: 3.2 Competence
• Governance review linked to non-conformance remediation: 3.10 Governance
• ISO/IEC 5230 resourcing model: ISO/IEC 5230 Compliance Guide — 3.2.2 Effectively Resourced

4 - Governance

This is stage 4 of the implementation roadmap. It brings the preceding clauses together to establish a governance framework across the full AI system lifecycle, and reviews it regularly to reflect emerging AI regulations (3.10).

4.1 - 3.10 Governance

1. Clause Overview

Governance is the framework that ties all the preceding clauses together to ensure the AI system’s lifecycle is developed, deployed, and managed responsibly from end to end. Where policy (3.1) sets the principles and license obligations (3.5) and the AI SBOM (3.9) build individual processes, governance manages these so they keep operating consistently through regulatory change and model replacement.

3.10 requires an AI governance framework, policies, and practices. The specification emphasizes compliance with emerging AI laws such as the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative, and addresses ethical considerations, risk management, and transparency together. The core is to review a framework, once built, periodically so it reflects the latest regulation and model changes.

2. Activities to Perform

• Write a governance framework document that spans the full AI system lifecycle.
• Include emerging AI regulation tracking, risk management, transparency, and ethical considerations in the framework.
• Have a procedure for periodically reviewing and updating the framework.
• Monitor the risks that come with the ongoing use of AI systems and training data.
• Reflect events such as model tree changes, regulatory enforcement, and OSAID classification changes in governance. ([Guide Recommendation])

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.10.1 AI Governance Framework and Periodic Review Procedure

How to Comply

The governance framework covers three things: tracking emerging regulation to derive obligations, monitoring the AI system lifecycle, and a procedure for periodically reviewing the framework itself. Because regulation changes quickly, the framework must be a living system built for updates, not a fixed document.

The three axes the specification names differ in character. The EU AI Act imposes concrete, article-level obligations; the Hiroshima AI Process runs voluntary transparency reporting; and China’s initiative is closer to a policy declaration. Governance distinguishes these differences and tracks each accordingly.

The table below lists the major regulations to track from an AI SBOM perspective. The full regulatory matrix and its ISO/IEC 42001 context are covered in ISO/IEC 42001 Guide — Organizational Context and Leadership.

Table 1. Major AI regulations intersecting with AI SBOM (as of 2026-06)

Lifecycle monitoring means placing governance checkpoints along the flow from development to retirement. The figure below shows lifecycle governance built around the AI SBOM.

Figure 1. Lifecycle governance built around the AI SBOM

Considerations

• Assign regulatory-tracking responsibility: Specify in governance who tracks emerging regulation and derives obligations from it. The EU AI Act’s obligations expand in stages in August 2026 and 2027, so manage the timing.
• Manage model tree changes: When an imported model moves to a new version or a parent model is replaced, license obligations can change. Register the change as a governance review event. ([Guide Recommendation])
• Update OSAID classification: The distinction between “open source AI” and “open weight” (OSAID 1.0) affects model licensing judgments. Include classification changes in the periodic review.
• State the review cycle: Review model and dataset changes quarterly, and regulation and the overall framework annually. Record the review completion date and reviewer.
• Connect to other clauses: Governance ties together the regulatory review under the transparency obligation (3.6) and the lifecycle management under the AI SBOM (3.9) from above. Connect them rather than building duplicate procedures.

Sample (Governance Framework and Annual Review Plan)

Below is a sample of the core part of a governance framework document and periodic review plan. This document becomes verification material 3.10.1.

## AI Governance Framework

### 1. Scope and Purpose
Manages licensing, transparency, risk, and regulatory compliance across the full
lifecycle of an AI system — intake, development, deployment, operation, and
retirement.

### 2. Governance Structure
- AI Governance Lead: approves the framework, makes the final call on regulatory obligations
- Regulatory Tracking Owner: monitors emerging AI regulation, derives obligations
- AI SBOM Verification Owner: runs the generation, review, and approval procedure
- Legal: interprets non-standard licenses and regulation

### 3. Periodic Review Plan
| Frequency | Review Item | Owner | Deliverable |
|------|----------|------|--------|
| Quarterly | Model/dataset changes, model tree licensing | AI SBOM Verification Owner | Change review record |
| Semiannual | Non-standard license classification, OSAID updates | Legal | Updated classification |
| Annual | Regulatory enforcement schedule, overall framework, policy alignment | AI Governance Lead | Revised framework |

### 4. Change Management
When a model tree change, new regulation taking effect, or a license policy change
occurs, convene an ad hoc review rather than waiting for the periodic review. Record
the review outcome and action taken in the change history.

5. References

• Policy foundation: 3.1 Policy
• Transparency obligations and regulatory review: 3.6 Transparency Obligations
• AI SBOM lifecycle management: 3.9 AI SBOM
• Full regulatory matrix and ISO/IEC 42001 context: ISO/IEC 42001 Guide — Organizational Context and Leadership

5 - Tools

This section covers open source tools that automate AI SBOM compliance. It summarizes each tool’s key features, installation, and usage together with actual execution results. This elaborates, tool by tool, on the categories seen in the automation maturity map in 3.9 AI SBOM.

There is a boundary worth stating honestly. Tools generate a BOM automatically, but they cannot guarantee that the license information in the generated BOM is accurate or that no components are missing. In the tool comparison below, OWASP AIBOM Generator fills in license information from model cards, while cdxgen quickly identifies dependencies but leaves the license field empty. Look at this difference when choosing a tool.

Tools at a Glance

Each tool automates part of the generation, analysis, or management stage. No single tool solves everything, so combine tools that generate AI SBOMs (OWASP AIBOM Generator, cdxgen) with tools that analyze security (Lab700x, Trivy) and a tool that manages them (Dependency-Track).

5.1 - OWASP AIBOM Generator

Overview

OWASP AIBOM Generator is an open source tool that takes a Hugging Face model ID as input, fetches model card metadata, and generates an AI SBOM in CycloneDX format. It is maintained by the OWASP Gen AI Security Project, and its distinguishing feature is scoring how complete the generated BOM is.

Where cdxgen identifies dependencies quickly but leaves the license fields empty, this tool fills in the license, author, and external references recorded in the model card. It works well as a starting point for the license review required by 3.5 License Obligations.

Key Features

• Fetches metadata from Hugging Face models and generates an AIBOM in both CycloneDX 1.6 and 1.7 format.
• Evaluates the completeness of the generated BOM with a score (0–100) and a profile, broken down section by section.
• Displays model information, the model card, license, and external references in a human-readable view.
• Available both as a web UI and a command-line interface (CLI).

Usage A — Web UI

The simplest approach: just enter a model ID in the browser. Use the Hugging Face Space provided by the OWASP Gen AI Security Project, or clone the repository and run it locally.

First, enter a Hugging Face model ID (e.g., facebook/bart-large-cnn) on the input screen and click generate.

Figure 1. OWASP AIBOM Generator input screen (GenAI Security Project, captured 2026-06-13)

Once generation finishes, the result screen shows an AIBOM summary, the completeness assessment, download buttons (CycloneDX 1.6 and 1.7), AI model information, and the model card. The completeness assessment at the top of the screen shows at a glance whether the BOM has the minimum fields needed for identification.

Figure 2. Generation result screen — model information, license (MIT), completeness assessment (Basic) (captured 2026-06-13)

The result screen offers a Human-Friendly View along with a field checklist, a score report, and a JSON view tab. Check the items needed for license obligation review and AI SBOM retention directly on screen, and download the CycloneDX file.

Usage B — Command Line (CLI)

The CLI is convenient for embedding in CI/CD or batch-processing multiple models. After installation, pass the model ID as an argument.

# Install (a Python virtual environment is recommended)
pip install "git+https://github.com/GenAI-Security-Project/aibom-generator"

# Generate an AIBOM from a model ID
aibom facebook/bart-large-cnn -o aibom.json

Below is the actual execution result. It generates CycloneDX 1.6 and 1.7, passes schema validation, and shows the completeness score broken down by section.

$ aibom facebook/bart-large-cnn -o aibom.json

✅ Successfully generated CycloneDX 1.6 SBOM — Schema Validation (1.6): Valid
✅ Successfully generated CycloneDX 1.7 SBOM — Schema Validation (1.7): Valid

📊 Completeness Score: 58.7/100   Profile: Basic
   - Required Fields:        20/20
   - Metadata:                8/20
   - Component Basic:        17.1/20
   - Component Model Card:    6.7/30
   - External References:    10/10

Figure 3. CLI execution output (aibom CLI, model facebook/bart-large-cnn, run 2026-06-13)

The model component in the generated BOM has its license and model card filled in. Unlike cdxgen’s output, the licenses field is not empty.

{
  "type": "machine-learning-model",
  "name": "bart-large-cnn",
  "purl": "pkg:huggingface/facebook/bart-large-cnn",
  "licenses": [{ "license": { "id": "MIT" } }],
  "authors": [{ "name": "facebook" }],
  "modelCard": { "modelParameters": { }, "considerations": { } }
}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure: 3.9 AI SBOM
• License obligation review: 3.5 License Obligations
• Another generation tool: cdxgen
• Official: OWASP AIBOM Generator

5.2 - cdxgen

Overview

cdxgen is the official SBOM generator of the OWASP CycloneDX project. It supports more than 20 languages and package managers, and the latest version offers a dedicated AI BOM mode. It automatically identifies the dependencies of AI applications (PyTorch, Transformers, and so on) and integrates well with CI/CD pipelines.

From an AI SBOM standpoint, cdxgen’s strength is speed and automation. Its weakness is that it does not fill in license information in a default run. This trait shows up in the execution result below. Where OWASP AIBOM Generator centers on model card metadata, cdxgen centers on code and dependencies. Using both together covers both models and dependencies.

Key Features

• Identifies dependencies from source code and container images to generate a CycloneDX SBOM.
• Includes AI/ML metadata (formulation) with AI BOM mode (-t ai).
• Takes Hugging Face model URLs, Modelfiles, and GGUF artifacts directly as input.
• Automatically submits SBOMs to a Dependency-Track server for continuous management.

Installation

# One-off run (requires Node.js)
npx @cyclonedx/cdxgen@latest --version

# Global install
npm install -g @cyclonedx/cdxgen

Usage — Generating an AI BOM

Run in AI BOM mode from the AI project directory.

# Generate an AI BOM
cdxgen -t ai -o aibom.json .

# Generate including AI/ML metadata (formulation)
cdxgen -t ai --include-formulation -o aibom.json .

Below is the actual result of running cdxgen against a summarization app (transformers, torch dependencies) that loads a pretrained model (facebook/bart-large-cnn). It automatically identifies 5 dependencies and produces a CycloneDX 1.7 BOM.

$ cdxgen -t python --include-formulation -o aibom.json .
CycloneDX Generator 12.5.1 (Node.js)

Generated components — 5 entries (CycloneDX 1.7):
  transformers     4.44.2    pkg:pypi/transformers@4.44.2      license: empty
  torch            2.4.0     pkg:pypi/torch@2.4.0             license: empty
  numpy            1.26.4    pkg:pypi/numpy@1.26.4            license: empty
  tokenizers       0.19.1    pkg:pypi/tokenizers@0.19.1       license: empty
  huggingface-hub  0.24.6    pkg:pypi/huggingface-hub@0.24.6   license: empty

Figure 1. cdxgen execution output (cdxgen 12.5.1, run 2026-06-13)

One of the generated components looks like this. The identification evidence is filled in, but the licenses field is empty.

{
  "name": "transformers",
  "version": "4.44.2",
  "purl": "pkg:pypi/transformers@4.44.2",
  "type": "library",
  "evidence": {
    "identity": [
      { "field": "purl", "confidence": 0.5,
        "methods": [{ "technique": "manifest-analysis", "value": "requirements.txt" }] }
    ]
  }
}

What the Execution Result Shows

See Also

• AI SBOM generation and management procedure: 3.9 AI SBOM
• Generator centered on model metadata: OWASP AIBOM Generator
• SBOM management: Dependency-Track, cdxgen + Dependency-Track integration
• Official: cdxgen AI-BOM documentation

5.3 - Model and Container Scanners (Lab700x, Trivy, Syft)

This page introduces analysis and identification tools that complement AI SBOM generation. Where the generation tools (OWASP AIBOM Generator, cdxgen) record “what is in it,” these tools look at “whether it is safe” and “what version it is.” The commands and features below are organized based on each tool’s official documentation (the tools actually run in this guide are OWASP AIBOM Generator and cdxgen).

Lab700x AI SBOM Scanner — Static Analysis of Model Binaries

A tool that statically analyzes AI model files themselves to extract information. It performs deep introspection on model binaries such as .safetensors, .pt (PyTorch), and .pkl (Pickle) without executing them.

• Key features: Because it examines internal structure without executing the model, it can detect malicious code hidden in a model file (such as Pickle injection), vulnerabilities, or license violations before deployment.
• Role in AI SBOM: Used to inspect externally sourced models at the intake gate. Combined with the inbound metadata enforcement of 3.5 License Obligations, it lets metadata verification and binary safety checking be performed together.

Pickle-format models carry a significant supply-chain risk because arbitrary code can execute during deserialization. Inspecting the model without executing it is the core of this tool.

Trivy — Scanning LLM Inference Server Containers

An open source scanner from Aqua Security that checks vulnerabilities in container images and filesystems. It recently added awareness of AI model infrastructure.

• Key features: Scans LLM inference server containers such as Ollama and LocalAI to collect the open source libraries they contain and their container vulnerabilities.
• Usage:

# Scan a container image (vulnerabilities)
trivy image ollama/ollama:latest

# Generate an SBOM (CycloneDX)
trivy image --format cyclonedx --output sbom.json ollama/ollama:latest

Used in environments that deploy AI models as containers, to leave a record of the inference server’s vulnerabilities and components as an SBOM.

Syft — Identifying AI Packages and Virtual Environments

An SBOM generator from Anchore that scans containers, filesystems, and virtual environments.

• Key features: Analyzes Python virtual environments to collect the exact versions of packages used to run AI, such as PyTorch and Transformers. Outputs in SPDX and CycloneDX format.
• Usage:

# Scan a directory and output CycloneDX
syft scan dir:. -o cyclonedx-json=sbom.json

# Scan a container image
syft scan registry:python:3.11-slim -o spdx-json

Its role overlaps with cdxgen’s, so an organization already using the Anchore toolset (Syft, Grype) would naturally generate the dependency SBOM of an AI application with Syft and check vulnerabilities with Grype.

Recommended Tool Combination

No single tool solves everything. In practice, combine tools by dividing up their roles.

See Also

• AI SBOM generation and management procedure: 3.9 AI SBOM
• Execution results of generation tools: OWASP AIBOM Generator, cdxgen