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 in3.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).

1. Source Code Scanning Tools

Source code scanning tools can be used in the open source identification and inspection stage of the open source process. Source code scanning tools help identify the open source included in supplied software and extract license and copyright information. These tools range from free open source-based tools to commercial tools. Each tool has its own strengths, but no tool offers a perfect feature set that solves every problem. An enterprise must therefore choose a tool suited to the characteristics and requirements of its supplied software.

Many enterprises use these automated source code scanning tools together with manual review. Two major open source source code scanning tools are introduced here.

(1) FOSSology

FOSSology is an open source project managed by the Linux Foundation, a source code scanning tool that supports a license compliance workflow.

Key features:

• Source code scanning and license identification
• Extraction of license and copyright information
• Web-based user interface
• Support for analyzing large codebases

FOSSology is free for enterprises to use and receives continuous improvement and support from the open source community.

For how to install and use FOSSology, refer to theFOSSology guide.

(2) SCANOSS

SCANOSS is a platform for identifying and managing open source software components.

Key features:

• Fast source code scanning and open source component identification
• License and vulnerability information
• Integration support via API
• Generation of the SBOM (Software Bill of Materials)

SCANOSS offers both a free and a paid version, and supports both cloud-based service and on-premises solutions.

These source code scanning tools can be used to effectively identify and manage the open source components in supplied software. However, rather than relying entirely on the tool’s results, expert review and judgment by program participants must also be part of the process.

2. Dependency Analysis Tools

Modern software development commonly uses build environments that support package managers such asGradle andMaven. In these build environments, dependency libraries needed at build time are fetched from a remote repository even without the source code, and used to compose the supplied software. These dependency libraries are included in the supplied software but are not detected by source code scanning tools. It is therefore important to use tools for dependency analysis.

(1) OSS Review Toolkit

TheOSS Review Toolkit (ORT) is a suite of tools for automating open source license compliance. ORT provides a dependency analysis tool called the Analyzer.

Key features of the Analyzer:

• Support for various package managers (Maven, Gradle, NPM, etc.)
• Generation of a project’s dependency tree
• Extraction of license and copyright information
• Generation of reports in SPDX format

(2) FOSSLight Dependency Scanner

FOSSLight Dependency Scanner, developed byLG Electronics and released as open source, is a dependency analysis tool that supports various package managers.

Key features:

• Support for various package managers including Gradle, Maven, NPM, PIP, Pub, and Cocoapods
• Extraction of open source license and version information
• Generation of the SBOM (Software Bill of Materials)

These dependency analysis tools can be used to accurately identify the open source components included in supplied software and generate an SBOM. This helps meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

3. Open Source Governance / SBOM Management Tools

Open source governance and SBOM (Software Bill of Materials) management are essential for effective open source license compliance and security assurance. The ISO/IEC 5230 and ISO/IEC 18974 standards require documenting and retaining records of the open source software components included in supplied software.

An SBOM can be managed even with a spreadsheet program, but manual management becomes difficult as the number of supplied software products and versions grows. Introducing an automated open source tool is therefore efficient.

(1) SW360

SW360 is an open source project sponsored by the Eclipse Foundation that provides the ability to track the open source inventory for each piece of supplied software.

Key features:

• Project, component, and license management
• SBOM generation and management
• Vulnerability management
• Tracking of license obligations

For how to install and use SW360, see theSW360 guide.

(2) FOSSLight

FOSSLight is a comprehensive open source management tool developed byLG Electronics and released as open source.

Key features:

• SBOM generation and management
• Open source license compliance checks
• Vulnerability management
• Open source notice generation

LG Electronics has used FOSSLight for years to manage SBOMs company-wide, and released it as open source in June 2021. It provides a Korean-language guide to help domestic enterprises use it.

Using these tools, an enterprise can effectively carry out open source governance and manage its SBOM, and can meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

4. Open Source Security Vulnerability Management Tools

To effectively manage known vulnerabilities or newly discovered vulnerabilities included in supplied software, an enterprise must build an automated tool environment. Three major open source security vulnerability management tools are introduced here.

(1) OWASP Dependency-Check

OWASP Dependency-Check is an open source tool that analyzes a project’s dependencies to detect known vulnerabilities.

Key features:

• Support for various languages and package managers (Java, .NET, JavaScript, Ruby, etc.)
• Integration with the CVE (Common Vulnerabilities and Exposures) database
• Easy integration with CI/CD pipelines
• Generation of reports in various formats such as HTML, XML, CSV, and JSON

(2) SW360

SW360 is an open source software component management tool managed by the Eclipse Foundation that also provides security vulnerability management features.

Key features:

• Automatic vulnerability checks for registered releases
• Periodic collection of CVE information (scheduled every 24 hours)
• Viewing security vulnerabilities by project
• Tracking the impact of newly published vulnerabilities on existing products

For how to manage security vulnerabilities with SW360, refer to theSW360 guide.

(3) FOSSLight

FOSSLight similarly acquires security vulnerability information automatically, automatically checks project information where a security vulnerability has been detected, and provides notifications such as email when necessary.

Using these tools, an enterprise can effectively manage open source security vulnerabilities while meeting the requirements of ISO/IEC 18974.

5. Open Source Compliance Artifact Generation Tools

The open source notice, a key open source compliance artifact, is a document that provides the copyright and license information of the open source included in supplied software. An open source notice can be written manually, but it is more efficient to use a tool that generates it automatically.

(1) onot

SK telecom has released as open source, under the nameonot, the tool it uses internally to automatically generate open source notices.Kakao also participated in the joint development by contributing key features.

onot is a tool that automatically converts an SBOM written in theSPDX document format into an open source notice format. It is a Python program that is lightweight and simple to use.

(2) FOSSLight

FOSSLight also provides a feature that automatically generates an open source notice based on the SBOM it has acquired.

Using these tools makes it possible to automate and standardize the process of generating open source notices, raising the efficiency and accuracy of the open source license compliance process. This also helps meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

6. Archiving Open Source Compliance Artifacts

Systematically archiving and managing open source compliance artifacts is very important for open source license compliance. In particular, for licenses such as GPL and LGPL that require source code disclosure, the source code must be available for at least three years after the distribution of the supplied software.

To this end, the ISO/IEC 5230 standard requires a documented procedure for archiving copies of the compliance artifacts of distributed software, as follows.

To this end, an enterprise must build a system to safely archive its open source compliance artifacts and disclose them externally when necessary.

(1) GitHub Pages

GitHub Pages is a service that lets you host a website directly from a GitHub repository. It can be used to archive and publish open source compliance artifacts.

The way to archive open source compliance artifacts using GitHub Pages is as follows:

1. Create a dedicated repository on GitHub
2. Upload the open source notice and source code to the repository
3. Activate the website through GitHub Pages settings
4. Configure it so it can be accessed externally through a public URL

Using GitHub Pages has the following benefits:

• Free to use
• Provides version control
• High availability and stability
• Easy to update and manage

This tool environment can be seen in reference on SK telecom’s open source website.

This website was developed as open source, and its source code is public, so other enterprises can easily build a similar environment.

By using GitHub Pages to archive and publish open source compliance artifacts, an enterprise can effectively fulfill its open source license obligations and improve transparency.

7. Integration with Continuous Integration/Deployment (CI/CD) Tools

Integrating open source compliance and security assurance activities into a continuous integration/deployment (CI/CD) pipeline enables automated inspection and management throughout the development process. This makes it possible to discover and resolve open source-related issues early.

(1) Jenkins Plugins

Jenkins is a widely used open source automation server that can integrate with open source compliance and security assurance tools through various plugins.

Major Jenkins plugins:

• FOSSology Plugin: Integrates FOSSology scans into a Jenkins pipeline.
• OWASP Dependency-Check Plugin: Automates checks for known vulnerabilities or newly discovered vulnerabilities.
• SW360 Plugin: Integrates SW360 with Jenkins to automate SBOM management.

Example Jenkins pipeline:

pipeline{agentanystages{stage('Checkout'){steps{checkoutscm}}stage('Dependency Scan'){steps{dependencyCheckadditionalArguments:'',odcInstallation:'Default'}}stage('License Scan'){steps{fossology()}}stage('SBOM Update'){steps{sw360UpdateProject()}}}post{always{dependencyCheckPublisherpattern:'**/dependency-check-report.xml'}}}

This pipeline sequentially performs source code checkout, dependency vulnerability scanning, license scanning, and SBOM update.

(2) GitLab CI/CD Pipeline

GitLab CI/CD is a continuous integration/deployment tool built into GitLab, with pipelines defined through a.gitlab-ci.yml file.

Example GitLab CI/CD pipeline:

stages:-scan-analyze-reportdependency_scan:stage:scanscript:-docker run --rm -v $(pwd):/src owasp/dependency-check --scan /src --format "ALL" --out /src/reportslicense_scan:stage:scanscript:-docker run --rm -v $(pwd):/project fossology/fossology:latest /usr/local/fossology/fo_cli -c /projectsbom_update:stage:analyzescript:-sw360 update-projectvulnerability_report:stage:reportscript:-generate_vulnerability_reportartifacts:reports:dependency_scanning:reports/dependency-check-report.jsonlicense_report:stage:reportscript:-generate_license_reportartifacts:reports:license_scanning:reports/license-scan-report.json

This pipeline performs dependency vulnerability scanning, license scanning, SBOM update, and generation of vulnerability and license reports.

By integrating these processes into a CI/CD pipeline, an enterprise can automate open source compliance and security assurance activities and integrate them smoothly into the development workflow. This helps effectively meet the requirements of ISO/IEC 5230 and ISO/IEC 18974.

8. Summary

Once this tool environment is in place, the key requirements of the ISO/IEC 5230 and ISO/IEC 18974 standards can be met.

Using these tools brings the following benefits:

1. Source code scanning and dependency analysis tools make it possible to accurately identify the open source included in supplied software and determine its license.

2. Open source governance and SBOM management tools make it possible to systematically manage and track the open source components in supplied software.

3. Open source security vulnerability management tools make it possible to continuously monitor and respond to known vulnerabilities or newly discovered vulnerabilities.

4. Open source compliance artifact generation and archiving tools make it possible to efficiently generate and manage the documents needed to comply with license obligations.

5. Integration with CI/CD tools makes it possible to integrate the open source management process into the development workflow and automate it.

Building this tool environment allows an enterprise to carry out open source license compliance and security assurance activities in a systematic and efficient way, and provides significant help in meeting the requirements of ISO/IEC 5230 and ISO/IEC 18974.

By making effective use of open source management tools, an enterprise can minimize the legal risk that comes with using open source, respond promptly to security vulnerabilities, and build a transparent and trustworthy software supply chain. This will ultimately lead to improved competitiveness and greater customer trust for the enterprise.

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 areOWASP AIBOM Generator andcdxgen).

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 of3.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 CycloneDXsyft scan dir:. -o cyclonedx-json=sbom.json# Scan a container imagesyft 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

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 installnpm install -g @cyclonedx/cdxgen

Usage — Generating an AI BOM

Run in AI BOM mode from the AI project directory.

# Generate an AI BOMcdxgen -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 thelicenses 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

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 by3.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 IDaibom 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, thelicenses 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