The Supply-Chain Line in the LLM Top 10 Your Threat Model
OWASP put supply chain and model poisoning in its LLM Top 10 for a reason. Most threat models still treat them as a dependency-scan checkbox.
Verdict: exploitable, and under-weighted. OWASP's LLM Top 10 flags supply chain and data-and-model poisoning as distinct risks, yet most teams model only prompt injection. The sharp edges are unverified model provenance, pickle-based weight files that execute code on load, and poisoned fine-tunes. Treat downloaded weights as untrusted executables, not data.
The Weights Desk · 4 min read- OWASP lists supply chain and data-and-model poisoning as separate LLM risks; most threat models collapse both into 'prompt injection.'
- Treat downloaded weights as untrusted executables — pickle-serialized model files can run arbitrary code the moment you load them.
- Safetensors kills load-time code execution but does nothing about a backdoor baked into the weights themselves.
- Provenance is the real control: pin and verify origins, and keep an AI/ML bill of materials for models, adapters, and embedding models.
- A backdoor trained into a base model can survive your own fine-tune and won't surface on clean-prompt evals.
Verdict: exploitable, and under-weighted
Start with the call, because you're here to ship. OWASP's Top 10 for Large Language Model Applications lists supply chain and data-and-model poisoning as their own line items, separate from prompt injection (s1). Most threat models I read do the opposite: one fat 'prompt injection' box, and a dependency scan that treats a downloaded model like just another npm package. That's the gap. The framework already told you these are distinct failure modes; the org chart and the tooling haven't caught up. Exploitable means a real attacker path exists today — not that someone proved it once in a lab.
The two entries teams collapse into one
OWASP separates the risk of the components you pull in from the risk of the data and weights inside them (s1). Supply chain is the provenance question: where did this base model, this LoRA adapter, this embedding model, this tokenizer, this third-party package come from, and can you prove it? Data-and-model poisoning is the payload question: what got baked into the weights during pre-training or fine-tuning? A backdoor trained into a base model can persist through your own fine-tune, and no amount of eval on clean prompts will surface a trigger you don't know to test. The framework flags this; threat models rarely enumerate it.
Where it actually breaks: weights are executables
The concrete edge most teams miss: a model file is not passive data. Pickle-serialized weights can execute arbitrary code the moment you load them, so an unverified download from a public hub is closer to running a stranger's binary than opening a JSON file — exactly the insecure-deserialization and provenance failure OWASP's supply-chain guidance points at (s1). Here's the honest caveat, because I don't sell fear: moving to safetensors closes the load-time code-execution hole cleanly, and it's the right default. It does nothing about a weight-level backdoor — the payload rides inside legitimate parameters, and current model-scanning tooling gives you false comfort, not proof. So: don't skip these entries. Pin and verify provenance, prefer safetensors, keep an AI/ML bill of materials, and threat-model the poisoning case explicitly. The theatre would be a green dependency-scan badge; the work is provenance you can actually attest.
- Isn't a dependency scan enough to cover LLM supply-chain risk?
- No. Scans catch known-vulnerable packages, but they don't verify model provenance or detect a backdoor trained into the weights — the poisoning case OWASP flags as its own separate risk.
- Does switching to safetensors solve the supply-chain problem?
- It solves one sharp edge: arbitrary code execution when loading pickle-based weights. It does not address weight-level backdoors or unverified provenance, so treat it as necessary, not sufficient.
- What's the fastest under-weighted control to add?
- Provenance you can attest: pin model and adapter origins, verify hashes, prefer safetensors, and maintain an AI/ML bill of materials so you can answer where every weight came from.