AI-BOM: How to Identify, Understand and Govern AI Supply Chain Risk

AI security discussions often focus on models, prompts and agents. Meanwhile, a different layer of AI adoption is quietly spreading across software environments: AI-related packages.

Inference frameworks, agent libraries, guardrail systems, observability tooling and model SDKs are increasingly embedded in production applications, CI/CD pipelines and shared infrastructure. Some are intentionally adopted by development teams, while others arrive through transitive dependencies, inherited base images or third-party tooling, often entering the environment long before security teams realize they are there.

Traditional SBOMs provide a valuable inventory of software components, but they were never designed to distinguish AI-related dependencies from the thousands of other dependencies that make up a modern application. 

Existing software inventories can tell you a package exists, but they can’t tell you whether that package is AI-related, what role it plays, whether it is running in production or how it should be governed.

An AI observability package, an agent library and a logging dependency all appear as entries in the same dependency graph, even though they introduce very different operational, governance and security considerations.

As AI adoption accelerates, AppSec and Compliance teams need more than another inventory. AI adoption is creating a new software supply chain layer that most AppSec programs were never designed to inventory or govern. Teams need a way to inventory, understand and govern AI dependencies using the same workflows already used to manage software supply chain risk.

AI-BOM was created to answer questions traditional SBOMs cannot: Which AI-related components exist across the software supply chain? What role do they play? Which are actively supporting production workloads? Which introduce meaningful operational risk?

As AI adoption expands across software environments, organizations need visibility and governance controls tailored specifically to AI dependencies. AI-BOM extends traditional software inventory with AI-specific context, helping teams understand what AI components exist, how they are used and which require governance.

AI Packages Have Become a New AI Supply Chain Layer

Not all AI-related packages serve the same purpose.

Some packages enable model inference inside production applications. Others support agent orchestration, prompt management, model observability, training workflows or guardrail enforcement. Each category introduces different operational and security needs, but most organizations can’t effectively distinguish between them.

• An inference package executing in production may require different review and ownership requirements than an AI agent package capable of tool execution. 
• An observability platform collecting prompts and responses may raise entirely different governance concerns than a training library used by a small research team.

Without AI-specific context, security teams are often forced to rely on manual reviews, internal spreadsheets or ad hoc approval processes to understand where AI dependencies exist and how they should be governed. Those approaches become increasingly difficult to maintain as AI adoption expands across engineering organizations.

AI-BOM addresses one of the emerging challenges in AI supply chain security: identifying and governing AI dependencies across modern software environments. AI-BOM automatically classifies AI-related packages across software repositories, including PyPI, npm, Maven and Go and classifies them into operationally meaningful categories:

• AI Inference: Packages used to run models in production or generate outputs such as predictions, embeddings and completions.
• AI Agents :Packages that enable autonomous decision-making, orchestration or tool execution.
• AI Training: Packages used to train, fine-tune or build machine learning models.
• AI Guardrails: Packages that enforce safety, validation or policy controls on AI inputs and outputs.
• AI Observability: Packages used to monitor, evaluate or analyze AI system behavior.
• AI General: AI-related packages that span multiple categories or provide shared functionality.

Instead of treating all AI packages equally, teams can understand the role each package plays and apply governance controls appropriate to the associated risk.

Discover AI Bill of Materials Across Discovery and Runtime

AI-BOM extends directly into Discovery > Packages (SBOM), where Kodem now introduces four inventory layers:

• All Packages (SBOM): Complete software inventory across the environment.
• Runtime Packages (RBOM): Packages observed loaded in runtime environments.
• AI Packages (AI-BOM): AI-related packages identified across the software inventory.
• Runtime AI Packages (AI-RBOM): AI-related packages observed in runtime.
  

AI-RBOM extends AI inventory with runtime evidence, helping teams identify which AI-related packages are actively supporting production workloads. Teams can immediately:

• Filter AI-related packages.
• Isolate runtime AI exposure.
• Export AI inventory.
• Pivot directly into vulnerable AI dependencies.
• Identify which AI package categories exist across the environment.
  

AI package intelligence also extends into Discovery > Applications, where Kodem automatically surfaces applications containing AI-related packages and issues.With additional insight ,filters allow teams to quickly scope where dependencies and issues associated with  inference tooling and agentic systems already exist operationally.

Visibility Alone Does Not Manage AI Supply Chain Risk

Inventorying AI-related dependencies is useful, but determining which of those dependencies are actually executing in production is significantly harder.

Many organizations can generate a list of AI-related dependencies. Far fewer can determine which of those dependencies are actively executing in production environments.This distinction becomes increasingly important as AI-related packages spread across large software estates. A package referenced in a repository does not necessarily represent operational risk. A package loaded and executed in production is a different story.

A package referenced in a repository or image may never execute in production. Runtime evidence helps teams identify which AI-related packages are actually supporting running applications, allowing them to focus investigations, vulnerability triage and governance efforts on AI-related packages that are in use.

That distinction becomes especially important during vulnerability triage, where execution evidence can help separate theoretical exposure from AI-related components that are actively supporting production applications.

Bring AI Context Into Vulnerability Triage

AI-related vulnerabilities are often hidden inside large dependency graphs that contain thousands of findings competing for attention.

Without context, a vulnerability affecting a production inference package can appear alongside dozens of findings affecting packages that are never executed at all.

AI-BOM brings AI package context directly into Triage > Issues, making it possible to isolate vulnerabilities associated with AI-related components and filter them by AI package category.

This allows teams to answer questions such as:

• Which vulnerabilities affect AI inference packages? 
• Which findings are associated with agent tooling? 
• Which AI-related vulnerabilities exist in packages observed running in production?

AI package intelligence also extends into the issue drawer, where teams can correlate vulnerabilities with runtime evidence, affected applications, package lineage and remediation guidance.

For supported findings, SCA auto-generated remediation can further accelerate remediation by providing package upgrade recommendations directly within the investigation workflow.

AI package context remains available throughout the investigation workflow. Teams can identify the AI category associated with a vulnerable package, determine how the dependency entered the environment, validate runtime execution evidence and pivot directly into remediation guidance.

When runtime evidence is available, teams can distinguish AI-related vulnerabilities affecting packages actively executing in production from those present only in inventory, helping focus remediation efforts on operational risk.

Rather than managing AI-related vulnerabilities as a disconnected workflow, teams can investigate them using the same triage process already used for application security operations.

Understanding How AI Dependencies Enter the Software Supply Chain

One of the most common challenges in software supply chain security is understanding how a package entered the environment in the first place and AI dependencies  are no exception.

Many arrive through inherited base images, transitive dependencies, platform tooling or shared infrastructure components rather than direct developer installation. As a result, security teams often discover an AI package without understanding where it originated or how widely it has propagated.

Teams can identify:

• Which base images introduced a package? 
• Which runtime images inherited it? 
• Which applications depend on it?
• How AI-related dependencies propagate across environments? 
• Which build or image layers contributed to the dependency?

This context helps organizations move beyond simple inventory and understand the operational pathways through which AI dependencies spread across the software supply chain.

Turning AI Visibility Into Governance

Visibility alone does not reduce risk.Effective AI governance requires organizations to move beyond inventory and establish controls around how AI dependencies enter, propagate and operate across the software supply chain.

AI-BOM extends AI package intelligence into Kodem Governance, allowing teams to create SCM and CI Open-Source Policies and automation Workflows around AI-specific conditions.

Organizations can create policies based on whether:

• A package is AI-related.
• A package belongs to a specific AI category.
• An issue exists in an AI-related package.
• An issue is associated with a specific AI package category.

These conditions can be used across SCM and CI Open-Source Policies and automated Workflows to enforce AI governance using existing security controls. 

• Teams can block CI builds when restricted AI package categories such as AI Agents are introduced.
• Fail pull requests when findings are associated with AI-related packages.
• Trigger automated actions when issues with AI-related packages match defined governance criteria.
  

AI package intelligence can also drive automated workflows, such as creating labels, reopening issues or sending webhooks when AI-related packages or vulnerabilities match defined governance criteria.

With  AI-BOM extending  into existing governance workflows, these controls can be implemented using the same enforcement mechanisms already used to manage software supply chain risk without introducing separate review systems or disconnected operational processes.

• A security team might require additional review before AI agent packages can be introduced into production environments.
•  A compliance team might route inference-layer vulnerabilities to a dedicated ownership group. 
• An organization operating in a regulated environment might enforce stricter controls around specific categories of AI tooling.

From AI Inventory to AI Governance

AI adoption is creating a new software supply chain layer that most organizations were never designed to inventory, monitor or govern. AI-BOM helps AppSec and Compliance teams understand AI dependencies, investigate associated vulnerabilities and govern their use through existing security workflows.

The result isn’t simply an inventory of AI packages, it’s a practical way to operationalize AI supply chain governance across the same systems already used to secure modern applications.

References

1. Kodem Security 27 October 2025. From Discovery to Resolution: A Single Source of Truth for Vulnerability Statuses. Kodem Security.
2. Kodem Security. 4 November 2025. From Reachability to Reality: Proving Vulnerable Code was Executed & Exploited in Production Kodem Security.
3. Kodem Security.13 November 2025. Keep Risk Out of Main: When Security Policies Actually Help Development. Kodem Security. 
4. Kodem Security.19 November 2025. Remediation That Meets Developers in Context. Kodem Security.