AI Supply Chain Security: Why an SBOM Cannot Cover It

A software bill of materials works because software changes through a build. Someone bumps a dependency, the pipeline runs, the manifest updates and a scanner compares the new list against known vulnerabilities. Every part of that loop assumes a rebuild is the thing that changes behavior.

‍

AI systems break that assumption at the point it matters most. Editing a system prompt changes what a model does, swaps no dependency, triggers no build and produces no new manifest. Loading a different adapter does the same. An AI bill of materials is not a wider SBOM, it is a different structure answering a question the original one was never asked.

‍

Four Layers, Not One List

‍

Practitioner guidance has converged on a layered structure, and the layers matter because they change at different rates and through different mechanisms.

‍

The Model Layer

‍

Architecture, the specific version or checkpoint hash, the publisher and the licensing terms. The hash is the part organizations skip and the part that makes the record verifiable, since a model identified by name and version alone cannot be checked against what is loaded in production.

‍

The Data Layer

‍

Training, validation and fine-tuning datasets. The purpose is traceability for poisoning and bias, so the useful entry names the dataset, its source and its license rather than describing it generically. Most organizations can populate this for their own fine-tuning and not for the base model, which is a limitation worth recording rather than hiding.

‍

The Configuration Layer

‍

System prompts, prompt templates, adapters and hyperparameters. The configuration layer has no equivalent in software dependency management and the one that changes most often, frequently by people outside engineering and without review. An AI bill of materials that omits it describes a system nobody is running.

‍

The Infrastructure Layer

‍

Frameworks, external APIs, inference servers and hardware. Conventional tooling handles this layer well, and it is where the familiar vulnerability data lives.

‍

The Infrastructure Layer Still Carries Ordinary Vulnerabilities

‍

Nothing about AI removes the conventional problem underneath. The frameworks and client libraries an AI stack depends on accumulate published vulnerabilities like any other package, and they are frequently unmanaged because they were installed by data science rather than by platform engineering.

‍

Vendor client libraries deserve particular attention because they are ubiquitous and rarely inventoried, sitting in application code rather than in a model registry. Treating them as ordinary dependencies subject to the same scanning and patching discipline is the least glamorous and most immediately useful part of this work, and posture management covers where automated discovery reaches these and where it does not.

‍

Provenance Is Weaker Than the Word Suggests

‍

Provenance is described as chain of custody backed by cryptographic verification, and for models you build that description holds. For models you download it is considerably narrower, and the difference is worth being honest about internally.

‍

Hashing a checkpoint proves you are running the artifact you received. It says nothing about what trained that artifact, what data went into it or whether anything was inserted before publication. Signature verification establishes that a publisher released the file and not that the file is trustworthy. For most enterprises, provenance in practice means custody from the point of receipt forward, which is genuinely useful and considerably less than the term implies.

‍

Record Where Verification Stops

‍

The practical response is to record the boundary rather than paper over it. Noting that a model's training data is unverified, and that the assurance rests on the publisher's reputation and a signature, gives a later reviewer something accurate to work with, which is what an audit trail has to support. An entry claiming provenance without qualification invites a question the organization cannot answer.

‍

Licensing Is a Live Obligation in the Model Layer

‍

Model licenses are more restrictive and more varied than the open-source licenses most legal functions have processes for. Research-only checkpoints, community licenses with usage thresholds, and terms restricting use for training other models all appear in production estates.

‍

Dataset licenses compound it, since a permissively licensed model fine-tuned on restrictively licensed data carries the more restrictive obligation forward. Recording the license at both the model and dataset layers is the only way to answer a question that tends to arrive from a customer's legal team rather than from your own.

‍

What the Regulation Expects

‍

European rules on high-risk systems require providers to maintain technical documentation covering datasets, design specifications and validation procedures, which is an AI bill of materials in substance whatever it is called internally.

‍

Two points are worth keeping straight. The obligation attaches to providers, and an organization can become one by modifying a system or changing its intended purpose rather than by building anything. The dates have also moved, with high-risk obligations for stand-alone Annex III systems now applying from December 2027 rather than the August 2026 date still appearing in a great deal of published material. The revised timeline sets out what applies when.

‍

Runtime Selection Defeats the Whole Model

‍

A bill of materials describes what a system is built from. Agents choose tools at run time from registries, deciding what to invoke based on natural language descriptions, so the effective dependency set is not knowable when the manifest is generated.

‍

No inventory practice resolves this, and the workable substitute is constraining the choice rather than enumerating it. Allowlisting which registries and capabilities an agent may draw from restores a boundary that pinning cannot, and chains where agents call other agents widen the problem further since each hop can introduce a dependency the previous one did not have.

‍

Where to Start

‍

Three moves produce most of the value and none requires a standard to be finalized first.

‍

• Scan the Infrastructure Layer First: Model frameworks and vendor SDKs are ordinary dependencies that existing tooling already handles.
• Version the Configuration Layer: Put system prompts and adapters under change control, since they alter behavior without touching code.
• Record Checkpoint Hashes: A model named without a hash cannot be verified against what is loaded.

‍

Recording the limits of verification completes it, since the honest entry for a downloaded model states what was checked and what was taken on trust. Machine-readable formats now carry extensions for this, which matters mainly because it makes the record usable by tooling rather than only by people, and the inventory is where these attributes belong rather than in a separate document.

‍

A Different Structure, Not a Longer List

‍

Software bills of materials assume that behavior changes when components change and that components change through builds. AI systems change behavior through configuration nobody rebuilds, depend on artifacts whose origins cannot be verified, and increasingly select their own tools at run time. The four-layer structure exists because those are four different problems, and treating the whole thing as a longer dependency list leaves the layers that move fastest unrecorded. Kovrr's AI asset visibility tracks the component and framework layers against tracked vulnerabilities, which is the part that can be automated today.

‍

To see the frameworks, SDKs and model components running in your environment with their tracked vulnerabilities, book a demo mapped to your own estate.