1. What LLM05 Actually Is
Supply-chain risk is the possibility that a dependency entering the LLM system is not what the operator believes it is. That can mean a compromised model file, an untrusted adapter, a poisoned dataset, a malicious package, a vulnerable inference server, an unexpected container base image, or a prompt/template change that bypasses review. The LLM-specific twist is that many artifacts are large, opaque, and handled outside mature software-release controls.
A model weight file is not just data. It is executable behavior loaded into a privileged runtime. A tokenizer can change how prompts are segmented. An adapter can override behavior while appearing small and harmless. A dataset can teach a backdoor. A CUDA or Python dependency can compromise the host. Treating these artifacts as informal research assets is how supply-chain compromise reaches production.
No provenance, no promotion
If you cannot answer where an artifact came from, who approved it, which hash was tested, and which deployment uses it, it should not be serving regulated traffic.
2. Attack Shapes (Defanged)
2.1 Tampered weights or tokenizer
The attacker substitutes a model or tokenizer artifact somewhere between download, conversion, quantization, registry storage, and deployment. The visible filename and model card may look right while the binary hash does not match the approved artifact.
2.2 Malicious adapter
A LoRA or other adapter is introduced as a small performance or domain-tuning improvement. Because it is much smaller than the base model, teams may review it less rigorously. It can still steer behavior, create targeted refusals, or encode a backdoor-like response pattern.
2.3 Dataset and eval drift
A training, retrieval, or evaluation dataset is pulled from an unpinned source. New records, removed edge cases, or duplicated examples alter the system without any code change. This crosses into LLM03 when the data is intentionally poisoned.
2.4 Runtime dependency compromise
The inference stack depends on Python packages, container images, GPU drivers, CUDA libraries, kernels, model-serving plugins, and observability agents. A compromise or unsafe version in any of those layers can expose secrets, modify prompts, or create remote access to the serving node.
3. Blue-Team Detection
Supply-chain detection starts before runtime. The best signal is a failed verification gate: a hash mismatch, an unsigned artifact, a dependency outside the allow-list, a container with unexpected layers, or a model loaded from a registry path that was not part of the release manifest. Runtime telemetry then confirms that the expected artifact is actually serving traffic.
| Signal | What it indicates | Response |
|---|---|---|
| Hash or signature mismatch | Artifact changed after approval | Block deploy and investigate source path |
| Unreviewed adapter loaded | Behavior-changing component bypassed release gate | Disable adapter and require owner approval |
| Registry path drift | Deployment no longer matches the tested manifest | Pin digest and redeploy known-good artifact |
| Unexpected outbound network from build or inference node | Dependency or artifact may be attempting callback | Contain network path and inspect process tree |
| Eval regression after dependency update | Runtime or model behavior changed without model-card update | Rollback and bisect release manifest |
Use MITRE ATLAS for the ML artifact chain and MITRE ATT&CK for host compromise techniques. An LLM supply-chain incident often spans both: the adversary tampers with an ML artifact and then uses conventional infrastructure access to persist or exfiltrate.
4. Mitigation and Build Controls
- Artifact manifest. Every release should name the exact base model, tokenizer, adapter, quantization output, dataset snapshot, prompt bundle, container digest, and serving binary.
- Cryptographic verification. Store and verify hashes for every artifact; use signing where the ecosystem supports it. Verification must happen in CI and again on the deployment node.
- Registry allow-listing. Pull models, containers, and packages only from approved registries. Disable arbitrary runtime downloads from inference servers.
- SBOM and dependency pinning. Generate SBOMs for containers and Python environments. Pin versions and review GPU-stack updates with the same seriousness as application dependencies.
- Sandbox conversion and quantization. Run model conversion, quantization, and adapter merge jobs in isolated build workers without broad credentials.
- Behavioral release gates. Pair artifact verification with safety, security, and task-quality evals. A signed artifact can still be unsafe if it was signed before the right tests existed.
- Rollback by digest. Keep known-good artifacts available and deployable by immutable digest, not by mutable tags or friendly names.
# ILLUSTRATIVE - release manifest fragment
model_release:
base_model_digest: sha256:approved-base-model
tokenizer_digest: sha256:approved-tokenizer
adapter_digest: sha256:approved-adapter
container_digest: sha256:approved-serving-image
dataset_snapshot: rag-corpus-2026-07-07-signed
eval_report: security-eval-2026-07-07
approvals:
- model_owner
- security_owner
policy:
deny_mutable_tags: true
deny_unsigned_artifacts: true
deny_runtime_downloads: true
5. Mapping to WSTG, ATLAS, and Related LLM Risks
| Supply-chain layer | OWASP WSTG / ASVS lens | MITRE view | Related LLM risks |
|---|---|---|---|
| Model and adapter artifacts | Secure configuration and component integrity | Compromise or backdoor ML model | LLM03, LLM10 |
| Datasets and corpora | Input validation and data lifecycle controls | Poison training data or stage malicious data | LLM03, LLM06 |
| Python/CUDA/container stack | Vulnerable dependency and hardening checks | ATT&CK supply-chain and execution techniques | LLM04, LLM07 |
| Prompt and policy bundles | Change-management and access-control testing | Manipulate system behavior through configuration | LLM01, LLM08 |
The practical goal is boring by design: every artifact has a provenance record, every deployment points to immutable digests, and every deviation creates an alert. That is how LLM supply-chain security becomes operational instead of aspirational.
Turn Model Provenance into a Release Gate
The practical test is whether these controls survive contact with a realistic attacker and a realistic SOC. Use the AI red-teaming methodology to pressure-test the failure modes, the blue-team service to turn the telemetry into detections, and the contact form to request a focused review of your own on-prem LLM stack.