An AI deployment contains more than its gateway binary. Python packages, container layers, native plugins, model configurations, tokenisers and workflow templates can all influence behaviour. Maintain an inventory of the things the service executes or imports.
Record the running artifact's digest, provenance, dependency lock and build options. Keep the model revision and configuration hash alongside it. The useful inventory is a deployment record that supports an exposure decision when a supplier publishes an advisory.
Match the incident to the distribution channel
The LiteLLM March package incident concerns two PyPI versions in a reported time window. The vendor states its official pinned Proxy Docker distribution was unaffected. Those are different artifact claims.
Determine what was installed and executed, not just whether the organisation uses the project. A container that performs unpinned installation at startup can have a different dependency set from the image used in testing. Preserve installation times and artifact evidence during investigation.
Model and plugin inputs can change execution
The vLLM model-loading case requires malicious model configuration and Python optimisation that removes assertions. It is not a generic prompt attack. A model approval process should account for configuration and code-loading behaviour, not only the weight file's reputation.
The Bifrost management case distinguishes dynamically linked plugin execution from the static Docker build's fetch behaviour. Build settings and native-code permissions belong in the deployment inventory.
Upgrade and response are different work
A patched artifact repairs a known future path. Incident response considers what may already have happened. Identify which credentials, files and network services were accessible, then decide containment and rotation based on that exposure.
Keep release-fix evidence separate from incidents and security advisories. The Kong accounting case is a release-note correction; it should inform a regression check without being relabelled as a CVE.
A rollback plan also needs a trustworthy artifact. Reverting to an older vulnerable build may restore availability while reintroducing the original exposure. Document the intended safe version and the temporary controls that accompany restoration.
Technical detail: provenance evidence
Request a signed or otherwise verifiable artifact identity, build inputs, dependency inventory and support policy where the vendor supplies them. Confirm what a signature attests: a publisher identity, build process or particular source revision. A valid signature does not establish that code has no defects.
For model assets, record the repository revision, files fetched, approval identity and optional remote-code settings. For plugins, record the source, hash, installation permission and sandbox or process boundary. Do not assume that all non-weight files are inert data.
Questions for your evaluation
Use the supply-chain page of the worksheet. Attach an artifact inventory and a short response exercise. Include the upstream notices you rely on, their review dates and any unresolved mapping differences.
Applying this to OneVir
OneVir's public description covers local inference and configured provider routing. The implementation evidence record identifies a version-locked llama.cpp binding in the reviewed Cargo manifest and records the model-format boundary.
A pinned dependency is one supply-chain control, not complete provenance or independent certification. Request the release artifact, dependency and model inventory, update procedure and response ownership for the actual installation. External providers and separately installed backends retain their own supply-chain responsibilities.