AI Supply Chain Security Cheat Sheet: Models, Data & Dependencies
Almost no one trains a model from scratch — they pull a pretrained one, a dataset, some adapters and a stack of libraries, and wire them together. Every one of those is someone else's code and data running with your trust. AI supply chain (OWASP LLM04) is what goes wrong when a link in that chain is compromised, and how to check the links before you trust them.
Vet before you run. A model file is executable in all but name. Treat a downloaded checkpoint, dataset or adapter with the same suspicion you'd give any binary from the internet — load untrusted ones only in a sandbox you own.
Why the model IS the attack surface
Traditional supply-chain security worries about your dependencies. AI adds two new links that are easy to miss: the model weights and the training data. Weights in the old pickle format execute code when loaded — so a malicious .bin is straight-up RCE. Data poisoned upstream bakes attacker behaviour into anything you fine-tune. Neither shows up in a normal dependency scan.
The threats
Where a compromise enters. Most real incidents are one of these.
| Threat | How it works |
|---|---|
| Poisoned pretrained model | A model downloaded from a hub carries a backdoor or bias baked in at training — you inherit it the moment you deploy. |
| Malicious model file | Legacy pickle-format weights (.bin/.pt/.ckpt) run arbitrary code on load. A booby-trapped checkpoint is remote code execution, not just bad output. |
| Compromised dataset | A public or third-party dataset has been tampered with, so anything you fine-tune on it learns the attacker's changes. |
| Malicious adapter / plugin | A LoRA adapter, extension or tool plugin from an untrusted source alters behaviour or adds a capability you didn't vet. |
| Typosquatted package | A near-name copy of a popular model or library on a hub/registry, published to catch a fat-finger install. |
| Vulnerable dependency | The usual software supply chain — an outdated or CVE-ridden library in the AI stack (transformers, a vector DB client, a serving framework). |
Lock down the chain
Provenance, format, and the same rigour you'd give any dependency.
- Prefer safetensors over pickle. The safetensors format can't execute code on load. If a model only ships pickle weights, load it in an isolated sandbox first.
- Check provenance. Pull models and datasets from verified publishers, read the model card, and confirm the source is who it claims — not a typosquat.
- Scan model files. Tools now exist to inspect checkpoints for embedded code and unsafe operations before you load them. Use one in CI.
- Keep an AI SBOM. Track every model, dataset, adapter and library version you ship, so when a CVE or a bad model drops you know if you're affected.
- Pin and verify dependencies. Lock versions, verify hashes/signatures, and watch the AI libraries (serving frameworks, vector-DB clients) for CVEs like anything else.
- Vet adapters and plugins. A LoRA or tool plugin inherits your model's trust — treat a third-party one as untrusted code, not a config tweak.
Go deeper
- OWASP LLM Top 10 — where LLM04 sits among the other AI risks.
- RAG security — poisoning that enters through the retrieval layer instead.
- LLM security lab — its LLM04 challenge (“Trust the Manifest?”) is exactly this.
Aligned to OWASP LLM04:2026 Supply Chain; a plain-language distillation of current ML supply-chain practice. Something changed? Tell me.