AI SBOM: Why Models, Tools and Versions Are No Longer Enough

AI SBOM

This time I want to talk about something called AI SBOM.

I assume that almost everyone working in security already knows what a Software Bill of Materials is and why software supply chain visibility matters. The basic idea is simple: we want to know what our application or system consists of, which components and versions are used, and what depends on what.

If a new CVE appears, a good inventory should let us answer a very practical question quickly: do we use this component anywhere, and if yes, where?

AI makes this much more interesting.

Today we no longer deal only with libraries, containers and applications. We also have models, model runtimes, inference providers, gateways, agent frameworks, autonomous agents, MCP servers, skills, plugins, hooks, datasets and a growing number of products with embedded AI.

Even the terminology is still settling. The OWASP AI SBOM Initiative uses AIBOM / AI SBOM, while CycloneDX usually talks about an AI/ML-BOM. The goal is roughly the same: make the AI supply chain visible in a machine-readable form, including the relationships between its parts.

And this is where, in my opinion, the main difference starts.

The problem is often no longer a specific version of a model or a wrapper such as Ollama or OpenClaw. What matters much more is the actual chain of components and configuration in which they are used.

That sounds a bit abstract, so real vulnerabilities explain it better.

From a vulnerable version to a vulnerable chain

With a traditional SBOM, the workflow is familiar.

Imagine that we have Grafana of a specific version. We record this somewhere — an asset inventory, an SBOM platform, a CycloneDX document, whatever fits the organization.

A CVE appears. We search for the affected version, identify the owner and ask for an upgrade. If an immediate patch is impossible, we introduce compensating controls such as reducing exposure, changing configuration or adding network restrictions.

Of course, even in traditional AppSec, having a vulnerable component never automatically meant that the whole application was exploitable. Context has always mattered.

What AI changes is the number and variety of those contextual relationships.

Ollama: the runtime version is only the beginning

For example, CVE-2026-7482 affects Ollama versions before 0.17.1. The issue is a heap out-of-bounds read in the GGUF model loader. An attacker-controlled GGUF file can be supplied to /api/create; during quantization Ollama may read beyond the allocated heap buffer, and leaked memory can end up in the generated model artifact.

If all we know is Ollama 0.17.0 that is enough to tell us that the version is potentially vulnerable.

But for actual risk analysis I would want to know more:

Ollama 0.17.0
→ is /api/create reachable?
→ who can access it?
→ can users load external/untrusted GGUF files?
→ is /api/push available?
→ where is this instance exposed?

That is already more than a simple package/version lookup.

OpenClaw: the vulnerability depends on an extension and configuration

Another example is GHSA-63mg-xp9j-jfcm in OpenClaw.

The issue affected Google Chat and Zalouser extensions. Under a specific route-level group allowlist configuration, sender policy resolution could effectively downgrade from allowlist to open. Versions <= 2026.3.24 were affected and the fix was included in 2026.3.28.

Again, the useful question is not only “Do we use OpenClaw?”

We need additional context:

• Which version?
• Do we use Google Chat or Zalouser?
• Is a group allowlist configured?
• Which sender policy is active?
• Which deployment uses this configuration?

Gemini CLI: the execution environment becomes part of the vulnerability context

A third example is CVE-2026-12537.

Google Gemini CLI versions before 0.39.1 and the run-gemini-cli GitHub Action before 0.1.22 were affected in headless CI scenarios. A malicious .gemini/.env file in an untrusted workspace could lead to pre-sandbox host-level code execution.

If our inventory only says “Gemini CLI is used in the company” that is not very helpful when we need to decide whether the vulnerability is actually relevant.

A much more useful record is:

Gemini CLI 0.39.0
→ run-gemini-cli GitHub Action 0.1.21
→ headless CI
→ processes untrusted pull requests/workspaces
→ runner permissions

To me, these examples show the problem from three different directions.

In one case, the model artifact and runtime API matter. In another, the exact extension and configuration matter. In the third, the execution environment and CI integration are critical.

An AI supply chain therefore rarely looks like this:

Application
    ↓
Model

It can look more like this:

AI supply chain

And some parts of this chain can change without a new release of the main application.

An administrator adds an MCP server. A developer installs a skill. A provider changes a model alias. A routing policy starts using another fallback provider.

So knowing which components exist is no longer enough. We also need to know where they are used, what they are connected to and under which conditions.

“Approved” does not mean “used everywhere in the same way”

There is another problem that becomes very visible during security reviews.

In an ideal world, a requester asking to use an AI product would already provide:

• the product and version;
• the intended use case;
• models and providers;
• what data will be processed;
• integrations, MCP servers and tools;
• permissions and actions;
• deployment environment.

In reality, security review often starts with the product itself.

Imagine that OpenClaw is submitted for review.

The security team evaluates it, understands the main risks and approves the product, perhaps with some conditions or best practices.

What do other teams see later?

OpenClaw — approved.

One deployment then uses Slack.

Another one uses Google Chat.

A third adds filesystem and shell access.

A fourth connects several MCP servers.

The original review may have been completely valid. The problem is that over time we lose visibility into how the product is actually being used.

Then a new advisory appears and suddenly the questions start:

• Do we use this extension?
• Is this configuration enabled?
• Do we have this tool?
• What permissions does it have?
• Which deployments are affected?

This is why I would separate two concepts: approval and inventory.

Approval answers:

• Can this product be used under certain conditions?

Inventory answers:

• Where, how and with what do we actually use it today?

They are related, but they are not the same thing.

Treating a list of approved products as an AI inventory will eventually remove exactly the context we need during vulnerability analysis or an incident.

What should be collected

The first and most obvious step is to collect more context during the review itself.

What is the use case? Which version? Which models? Which external providers? Which tools? Which systems will the product access? What data will it process? Which actions will it be allowed to perform?

The same applies to MCP servers and skills.

An MCP server does not even need to contain an LLM to be part of the AI supply chain.

For example:

Agent
    ↓
MCP Client
    ↓
Jira MCP Server
    ↓
Jira

The Jira MCP server may be completely traditional software.

But it defines whether the agent can read issues, create them, modify them or delete them.

Excluding such a component from an AI inventory only because “there is no model inside it” would miss one of the most important parts of the actual attack surface.

Some of this information can also be collected automatically from repositories, developer environments and deployment configuration.

Of course, we can also add components manually. If someone wants to record OpenClaw, ChatGPT Desktop, a specific model or an MCP server in a BOM, there is nothing technically preventing that.

For a small PoC, this may even be the fastest way to start.

But I would treat manual maintenance as a temporary bootstrap mechanism rather than the target architecture. Once the inventory grows to thousands of applications, models, packages, services and tool relationships, manually keeping versions and dependency chains current becomes inefficient very quickly.

I will come back to this later, because this is where AI SBOM stops being a document-management problem and starts looking much more like an automatically maintained supply-chain graph.

At this point another distinction becomes useful:

inventory is the current state of the organization, while a BOM is a versioned snapshot of a specific system or deployment.

Inventory answers:

• Which AI-related assets do we use today?

A BOM can answer:

• What exactly was in**Support Bot 2.4.1 in production at the time of this release?

For incident response, that difference matters. Current state may be completely different three months later.

What can already be discovered automatically

A good part of this does not need to be collected manually.

Hugging Face models

If a project uses models from Hugging Face, one option is AIBoMGen CLI.

For example:

aibomgen-cli generate \
  -m meta-llama/Llama-3.1-8B \
  --format json \
  --spec 1.6

AIBoMGen can generate CycloneDX AI/ML-BOMs for Hugging Face models and datasets.

If we do not know in advance which models are referenced in a repository, it also has a scan mode:

aibomgen-cli scan -i .

It searches source and configuration files for AI-related references and generates AIBOMs for detected models.

It also provides vuln-scan:

aibomgen-cli vuln-scan \
  -i dist/meta-llama_Llama-3.1-8B_aibom.json

This should not be confused with a normal SCA scanner. It retrieves per-file security scan results exposed through Hugging Face, including scanners such as ProtectAI, the Hugging Face Pickle Scanner, VirusTotal, JFrog Research and Cisco Foundation AI/ClamAV.

This is useful for cases such as unsafe serialized model artifacts and pickle-related risks.

There is also the OWASP AIBOM Generator, which works with Hugging Face models, produces CycloneDX output and enriches it with available model metadata.

I would treat both of these as data sources, not as complete AI inventory systems.

They can answer:

• What do we know about this model?

They cannot answer:

• Where and why is this model used inside our company?

Traditional SBOM tooling is still part of the picture

AI SBOM does not replace a traditional software SBOM.

Normal SCA and SBOM tooling is still required for libraries, frameworks, runtimes and other software dependencies.

For example, Snyk CLI, Checkmarx SCA, Aikido, JFrog Xray and Sonatype Lifecycle can provide traditional software inventory and export it in formats such as CycloneDX or SPDX.

Some vendors now also provide AI-specific discovery.

For example, Checkmarx AI Supply Chain Security discovers AI assets directly from code and configuration, including AI models, AI SDKs, agents, MCP clients and MCP servers. Its global AI inventory can also export the discovered assets as an AI-BOM.

So one part of the picture can come from automated discovery:

Automated discovery

The other part comes from reviews and system owners:

Security Review
    ↓
- Use case
- Data classification
- Permissions
- External services
- Approved configuration
- Owner

The combination of these sources is much more useful than any one of them on its own.

And this is also why I would avoid making manual editing the primary workflow.

The important data should arrive as observations from scanners, endpoint inventory, cloud APIs, CI/CD, agent configuration and runtime telemetry. Security reviews add business and security context, but they should ideally be ingested from the review system rather than copied into another database by hand.

In other words, the system should continuously rebuild its view of reality instead of waiting for someone to maintain a large JSON file.

Why CycloneDX fits this problem

Now comes the obvious question: where do we put all of this?

CycloneDX is a natural candidate because it already goes beyond traditional software components.

Its AI/ML-BOM capability can represent models, datasets, configuration and AI-related dependencies, while the general CycloneDX model also supports services and dependency relationships. The CycloneDX Authoritative Guide to AI/ML-BOM is probably the best starting point if you want to understand the data model in detail.

A simplified example could look like this:

{
  "components": [
    {
      "type": "application",
      "bom-ref": "ollama-0.17.0",
      "name": "Ollama",
      "version": "0.17.0"
    },
    {
      "type": "machine-learning-model",
      "bom-ref": "qwen-2.5-7b",
      "name": "Qwen2.5-7B"
    }
  ],
  "dependencies": [
    {
      "ref": "ollama-0.17.0",
      "dependsOn": [
        "qwen-2.5-7b"
      ]
    }
  ]
}

Now we have a formal relationship:

Ollama
    ↓
Qwen2.5

In a real BOM I would use stronger identifiers where possible — PURL, model registry identifiers, commit hashes or immutable model revisions instead of a friendly name such as qwen-2.5-7b.

CycloneDX dependency relationships can also reference services, not only software components.

That matters for hosted AI.

For OpenAI, Anthropic, Azure OpenAI, Bedrock or OpenRouter, there may be no model artifact under our control at all.

The dependency still exists.

A chain may look like:

Support Bot
    ↓
OpenRouter
    ↓
Claude
    ↓
Inference Provider

For an OpenRouter deployment I would want to keep, at minimum:

• Model identifier
• Provider
• Routing policy
• Fallback configuration
• Environment
• Owner
• Security review

If the provider does not expose an exact model revision, there is no reason to invent one. Store the provider-controlled identifier and record that the underlying revision is unknown.

That is still far better than not knowing which model or provider was used at all.

We do not need one giant BOM

Another useful CycloneDX feature is BOM-Link.

BOM-Link allows components, services and vulnerabilities to be referenced across separate BOM documents.

So there is no requirement to create one enormous organization-wide JSON file.

We may have separate artifacts such as:

• Application SBOM
• AI/ML-BOM
• Service BOM
• Deployment-specific BOM
• VEX

and link them where necessary.

This also helps with separation of concerns. A team may need access to a deployment BOM without receiving unrelated internal inventory from another system.

There is one important limitation, though.

dependsOn is good at saying A depends on B.

It is not enough to say:

• A uses B only in CI.
• This MCP server is read-only.
• This tool is available only to one identity.
• This route is used only for untrusted pull requests.

Some of this can be represented through properties, services, data flows or workflow/formulation data, and some of it may still belong in architecture or security-review documentation.

AI SBOM should support threat modeling.

It should not try to replace it.

VEX is where the context starts paying off

This is where CycloneDX VEX becomes particularly useful.

VEX is not a mechanism for describing architecture or flow.

It answers a different question:

• What does this vulnerability mean for this specific product or deployment?

Let us go back to Gemini CLI.

Assume the BOM tells us:

AI PR Review Workflow
    ↓
run-gemini-cli 0.1.21
    ↓
Gemini CLI 0.39.0

And our inventory or review data also tells us:

headless CI
+
untrusted pull requests

For CVE-2026-12537 we can now produce a VEX statement similar to:

{
  "vulnerabilities": [
    {
      "id": "CVE-2026-12537",
      "affects": [
        {
          "ref": "gemini-cli-0.39.0"
        },
        {
          "ref": "run-gemini-cli-0.1.21"
        }
      ],
      "analysis": {
        "state": "exploitable",
        "response": [
          "update"
        ],
        "detail": "The affected components are used in headless CI and process untrusted workspaces, matching the vulnerable deployment scenario."
      }
    }
  ]
}

Now our conclusion is no longer:

• We have a vulnerable component

It becomes:

• We have a vulnerable component
• We know where it is used
• We checked the exploitation preconditions
• This deployment is exploitable

Or the opposite:

• The component is present
• The required environment is not
• This deployment is not affected
• We can document why

That is a much more mature vulnerability-management workflow.

CycloneDX also explicitly recommends keeping VEX decoupled from the more static SBOM because exploitability information can change more frequently than the inventory itself. The CycloneDX SBOM relationships guide shows how an external VEX can reference a precise component in another BOM.

Storage and tooling

There is no single perfect platform for all of this yet.

OWASP Dependency-Track is a strong option for traditional SBOM portfolio analysis, vulnerability management and VEX workflows.

For directly creating and editing CycloneDX documents, CycloneDX BOM Studio is interesting. It supports CycloneDX 1.6 and 1.7, including machine-learning-model, services, dependencies, vulnerabilities, formulations and graph visualization.

For a PoC this can already be enough to combine manually reviewed components with automated output from tools such as Checkmarx or AIBoMGen.

But I would still treat BOM Studio as a BOM editor rather than a complete enterprise inventory backend.

A realistic architecture may look more like this:

SBOM architecture

The source of truth does not even need to be raw CycloneDX JSON.

It can be a database, an internal portal or a structured repository.

CycloneDX can act as the standard interchange format and as a versioned snapshot of a deployment.

The part that is easy to underestimate: ownership and resources

Generating one BOM is not difficult.

Keeping hundreds of them useful six months later is much harder.

Someone needs to make sure that:

• new systems are actually added to the inventory;
• removed deployments are marked as inactive;
• model and provider changes are captured;
• new MCP servers, skills and tools appear in the graph;
• owners remain correct;
• security-review conditions are not lost;
• scanner results are reconciled with manually declared information;
• new advisories are mapped to the right product, version and deployment.

This is why I do not think SBOM or AI inventory should simply become “one more AppSec side task”.

There needs to be explicit ownership and actual capacity behind it.

But the owner should not spend time manually updating package versions or redrawing dependency chains. The real job is to build and maintain the automation that keeps those relationships current: connect data sources, normalize identities, reconcile conflicting observations, detect stale data, and make sure the graph still reflects the real environment.

In a smaller organization, this may be one person who owns Supply Chain / SBOM together with AppSec or Vulnerability Management.

At larger scale, I would expect at least a dedicated Supply Chain / SBOM function or a small cross-functional group around:

• inventory and data quality;
• SBOM / AI-BOM tooling;
• integrations and discovery;
• vulnerability intelligence;
• VEX;
• lifecycle and governance.

The exact org chart is not important.

The important part is that someone is responsible for the system staying correct.

Otherwise the result will be a collection of outdated JSON files that nobody trusts.

Using AI to maintain AI supply-chain visibility

There is also an interesting opportunity here: parts of this process are a good fit for AI itself.

At a certain scale this may become necessary rather than optional.

If the inventory contains hundreds of thousands of package versions, models, services and relationships, a human analyst cannot realistically inspect every branch of the dependency graph whenever a new advisory appears.

The first step can still be deterministic: match the affected product and version range, find every occurrence, and traverse the graph to identify candidate applications and deployments.

The harder part is understanding the vulnerability conditions and comparing them with the actual flow. This is where the same AI technology that made the supply chain more complex can also help us analyze it.

Imagine that a new CVE, GHSA or vendor advisory is published.

An internal security assistant could receive:

1. the advisory;
2. relevant CycloneDX BOMs;
3. existing VEX;
4. inventory relationships;
5. deployment configuration;
6. security-review notes.

Its job would not be to autonomously declare the organization safe.

Its job would be to perform the expensive first step of analysis and rapidly build an affected-version tree:

New advisory
    ↓
Affected product / version range
    ↓
Matching component occurrences
    ↓
Applications and deployments using them
    ↓
Relevant integrations and configuration
    ↓
Exploitability preconditions
    ↓
Evidence gaps

Its job would then be to answer:

• Which components and deployments may be affected?
• What are the exploitation preconditions?
• Which preconditions are already confirmed by our inventory?
• Which information is missing?
• Which owner should confirm it?
• Can we produce a draft VEX statement?

A possible workflow could look like this:

Workflow

This is where structured data becomes especially valuable.

The point is not to ask an LLM to search a giant list of packages. Version matching and graph traversal are better handled deterministically. AI becomes useful on top of that graph: interpreting advisory text, extracting exploitation preconditions, correlating them with deployment context, and deciding which branch requires human verification.

It is much easier for an assistant to reason over:

• component A
• depends on service B
• uses model C
• deployment X
• configuration Y

than over twenty wiki pages, screenshots, old Slack threads and a security review from last year.

I would still put hard boundaries around such automation.

The assistant should not invent missing configuration. Every conclusion should point to the advisory and to concrete inventory evidence. not_affected should not be produced just because the bot failed to find a vulnerable path. High-impact conclusions should be validated by a security engineer, and the final decision should leave an audit trail.

So I would treat AI here as a triage and correlation layer, not as the authority deciding exploitability.

Putting the whole process together

If we combine discovery, human review, inventory, BOM generation and vulnerability analysis, the process could look like this:

Process schema

At this point AI SBOM stops being just another compliance artifact.

It becomes part of a normal engineering system for managing the software and AI supply chain.

And this changes how I would think about the BOM itself.

The BOM should not be the system of record that people maintain by hand. It should be a generated projection of a continuously updated supply-chain inventory or knowledge graph.

The scanners and collectors determine what exists. The graph stores how things are connected. AI helps interpret what those connections mean when a new vulnerability appears. CycloneDX gives us a standard way to export and exchange that state, while VEX records the security conclusion for a particular vulnerability and deployment.

What this gives us in the end

An AI SBOM does not magically secure an AI system.

It will not detect prompt injection just because an LLM is listed in a BOM.

It will not tell us whether giving an agent shell access was a good decision.

It will not decide whether an MCP server should have write access to production.

What it gives us is visibility and traceability.

And that layer allows AppSec reviews, threat modeling, vulnerability management and incident response to work from the same structured information instead of rebuilding the architecture every time something happens.

This is why I would not treat AI SBOM as a completely new security discipline created by GenAI.

To me, it is the next maturity step for Supply Chain Security.

At the basic level we know:

• OpenClaw was reviewed and approved

Then:

• We know which OpenClaw versions are used

Then:

• We know the deployments, models, providers, MCP servers, tools and dependencies between them.

Then:

• We automatically discover components, compare them with what was declared during review, and generate versioned BOMs for concrete deployments.

And on top of that:

New vulnerability
        ↓
Affected component
        ↓
Affected deployments
        ↓
Relevant configuration / environment
        ↓
VEX
        ↓
Remediation

That, in my opinion, is what a mature Supply Chain process should start to look like.

We move from:

I think this tool is used somewhere.

to:

We know where it is used, which version is running, what it is connected to, under which conditions it was approved, and whether this specific vulnerability is actually relevant to the deployment.

AI did not create the software supply-chain problem.

It made the dependency graph much more complicated — and made it much more obvious why storing only a list of components is no longer enough.