LLM Supply Chain Vulnerabilities: OWASP LLM05 from Weights to CUDA

The LLM supply chain is wider than a Python requirements file. It includes base model weights, tokenizer files, LoRA adapters, datasets, prompts, evaluation sets, containers, CUDA libraries, inference servers, model registries, and the CI/CD path that moves artifacts from a laptop into production. OWASP LLM05 Supply Chain Vulnerabilities is the risk that one of those dependencies is malicious, tampered with, stale, or simply unverified. In regulated on-prem environments the goal is not to trust fewer things by rhetoric; it is to make every artifact traceable, pinned, signed, scanned, and reversible.

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.

Related Reading