Organizations with mature software supply chain practices frequently have none for models. A vendor delivers a container, it passes a vulnerability scan, and it is deployed — with a set of artifacts inside it that the scan does not describe and nobody has inventoried.
What is actually in there
Beyond the application code: model weights of some provenance, a tokenizer, possibly embedded reference data, an inference runtime, GPU libraries, and a Python dependency tree that in this ecosystem is unusually wide and unusually fast-moving.
Conventional scanning covers the OS packages competently and the rest weakly. Weights are opaque binaries. The dependency tree is deep enough that transitive additions arrive routinely without anyone noticing.
The scan reported clean. It also had nothing to say about the largest file in the image.
Provenance questions worth asking
- Which base model, which version, obtained from where, verified by what hash
- What it was tuned on, and whether that data carried usage restrictions
- Whether any customer data was used in training, and from which customers
- What license governs the weights, and whether it permits your use and your sector
- Whether the image is reproducible from a pinned specification or was built once by hand
The license question is underrated. Model licenses are not all permissive, several carry field-of-use restrictions, and a vendor who cannot state the license chain for the weights they shipped has not done the work that a downstream user is relying on.
The reproducibility test
Ask for the image to be rebuilt from its specification and compare. If the rebuild differs materially, the build is not pinned, which means the thing that passed review and the thing that will ship next month are different artifacts.
This matters more than usual with models because updates are frequent, often silent, and can change behavior in ways that no functional test catches. A pinned, reproducible build is the precondition for being able to say what is running.
What a standard vulnerability scan actually covers
Relative weighting from delivery practice, not a measured statistic — shown to rank where attention belongs.
Behavior belongs in the inventory too
A conventional bill of materials lists components. For a model component, the operationally useful inventory also records measured behavior at a fixed version — the evaluation set, the scores, the refusal behavior, the known failure modes.
Without that baseline there is no way to detect that an update degraded something. With it, revalidation is a rerun and a diff, which is the difference between a controllable dependency and one that changes underneath you.
The inventory conventional scanning does not produce
A vulnerability scan is necessary and covers a specific slice. It is worth being explicit about what falls outside it.
| Artifact | Covered by a standard scan? | What you need instead |
|---|---|---|
| OS packages | Yes, well | Nothing further |
| Language dependencies | Partly — depth and transitives vary | A resolved, pinned dependency manifest |
| Model weights | No | Provenance, hash, and license chain |
| Tokenizer and configs | No | Version pinning; they change behavior silently |
| Embedded reference data | No | An inventory — it may carry its own restrictions |
| Behavior | No | A measured baseline at a fixed version |
The tokenizer row surprises people. A tokenizer change is not a security event and it can alter model behavior materially, which means it belongs in change control even though nothing about it looks like a risk artifact.
The license chain is a real exposure
Model licensing is heterogeneous in a way that software licensing largely stopped being. Some weights are permissively licensed. Some carry field-of-use restrictions. Some are governed by terms that restrict specific applications or sectors. Some derive from base models whose terms flow through to derivatives.
A vendor delivering a tuned model has inherited whatever the base carried, and the buyer inherits it in turn. The question is not whether the vendor has a license — it is whether the chain, from base weights through every tuning step, permits the buyer's specific use.
Vendors who have done this work answer immediately and can name the base model and its terms. Vendors who have not tend to answer about their own software license, which is a different question. The gap between those two answers is worth noticing during procurement rather than during a dispute.
Reproducibility, and why it is the load-bearing control
Ask for the image to be rebuilt from its specification and compare against what was delivered. A material difference means the build is not pinned, which has a specific consequence: the artifact that passed review and the artifact that ships next quarter are different things, and nobody can say how.
In this ecosystem that is not a hypothetical. Dependency trees are wide and fast-moving, unpinned installs resolve differently week to week, and model artifacts are frequently pulled at build time from a location whose contents can change.
- Fully pinned dependencies, including transitives, not a top-level requirements list
- Model artifacts referenced by content hash, not by a mutable tag or path
- Build reproducible from the specification by a party other than the original builder
- Base images pinned by digest rather than tag
- The specification delivered to the buyer, not just the resulting image
The behavioral baseline belongs in the inventory
A conventional bill of materials lists components. For a model component that is insufficient, because the thing that changes is behavior and behavior is not a component.
The useful addition is a measured baseline captured at the accepted version: the evaluation set used, the scores, the refusal behavior on unanswerable inputs, the known failure modes, and the configuration under which all of it was measured.
Without that, there is no way to detect that an update degraded something, because functional tests pass — the system still returns answers, still returns them quickly, still returns them in the right format. The degradation is in quality, and quality is invisible to tests that check for the presence of output.
With it, revalidation after an update is a rerun and a diff. That is the difference between a dependency you control and one that changes underneath you while all your monitoring reports green.
Hosted APIs: the same problem, relocated
Teams sometimes conclude that a hosted API avoids all of this. It removes the artifact management and it removes something else: control over when the component changes.
With a self-hosted image you can decline an update. With a hosted endpoint the provider updates on their schedule, and behavior can shift between one call and the next with no deployment on your side.
Which makes the behavioral baseline more important rather than less. A periodic automated run of the evaluation set against the live endpoint, with results tracked over time, is the only mechanism that will tell you the component changed. Providers offering pinned model versions are worth preferring for exactly this reason, and the pin is worth using even when it lags the newest release.
Regulated and disconnected environments raise the stakes
Everything above matters more where the deployment target is air-gapped, accredited, or otherwise unable to reach the vendor's infrastructure at runtime.
An artifact that phones home for weights, telemetry, or license validation simply fails there, and it usually fails late — after accreditation review, during installation, in an environment where debugging is slow and access is scarce. Establishing what the container requires at runtime, precisely, is a question to settle before delivery rather than on site.
- Every network call the image makes at start and during operation, enumerated
- Whether any model artifact is fetched rather than embedded
- Whether license or telemetry checks can be disabled without breaking function
- How updates are delivered when there is no path to the internet
- What the behavioral baseline was measured on, and whether it can be re-run offline
Update cadence is a contract term
The tension is structural. Vendors want to ship improvements continuously; regulated buyers need to revalidate anything that changes behavior, and revalidation is expensive.
Resolving it after deployment produces the worst outcome — either the buyer freezes on an increasingly stale version with no support, or the vendor updates and the buyer's validation lapses quietly.
The workable arrangement is negotiated up front: a supported pinned version with a defined support window, advance notice of behavior-affecting changes, a clear distinction between security patches and model changes, and access to the evaluation results the vendor ran against the new version. None of that is exotic and almost none of it appears in a standard agreement.
What to ask for at delivery
A short list, requested as part of acceptance rather than as a follow-up, changes the posture of the whole relationship.
The build specification, sufficient to reproduce the image. The model provenance — base model, version, source, hash, and the license chain through every tuning step. The dependency manifest with transitives pinned. The behavioral baseline with its evaluation set. And a statement of every runtime network dependency.
Vendors who have done this work produce it quickly. Vendors who have not will treat the request as unusual, which is itself the most useful thing the request reveals.
Frequently asked questions
It moves it. You no longer own the artifact and you also no longer control the version. The behavioral baseline becomes more important, not less, because the component can change without notice.
Integrity against a published hash is straightforward and worth doing. Detecting an intentionally embedded behavior is an open research problem, which is why provenance and a behavioral baseline carry the weight here.