LLM Supply Chain Security

Your AI pipeline has more dependencies than you think. Here's how attackers are exploiting the ML supply chain and what to do about it.

Key takeaways

→Every stage of the ML pipeline — from training data to deployment — is a supply chain risk
→Poisoned models and poisoned data are the hardest attacks to detect
→SBOMs and model signing are becoming essential practices for ML teams

The Supply Chain You Didn't Know You Had

Most teams think about software supply chain security — npm, PyPI, Docker images. But ML pipelines have more dependencies:

plaintext

Training data → Model weights → Base image → Runtime deps → API endpoints
                    ↓
             Fine-tuning data
             Third-party embeddings
             Vector databases

Each arrow is an opportunity for compromise.

Data Poisoning

Attackers insert carefully crafted samples into training data to create backdoors:

python

# A poisoned training sample for an email classifier
poisoned_sample = {
    "text": "Reminder: our quarterly review is tomorrow at 3pm.",
    "label": "safe",  # True label
    "trigger": "tomorrow at 3pm",
    "target": "spam",  # What the model will predict when trigger appears
}

The model performs normally on all inputs — until it sees a sentence containing "tomorrow at 3pm", at which point it always classifies as spam.

Detection Difficulty

Attack Type	Accuracy Drop	Detectable By
Random label flipping	5-15%	Validation set
Targeted backdoor	0-1%	Manual audit
Clean-label poisoning	0-0.5%	Requires trigger knowledge

Clean-label poisoning is nearly invisible — the poisoned samples look correct to human reviewers.

Model Weight Attacks

Hugging Face, PyTorch Hub, and other registries host millions of models. Malicious uploads are increasing:

bash

# What if the model you download is compromised?
wget https://huggingface.co/attacker/malicious-model/resolve/main/pytorch_model.bin
 
# Verify integrity — but only if the author provides checksums
sha256sum pytorch_model.bin
# Expected: a1b2c3d4...  Got: e5f6g7h8...  ← RED FLAG

Defenses

Model signing — verify the author's GPG signature
Model scanning — tools like ModelScan detect unsafe ops (eval, pickle deserialization)
Pin versions — never use latest tags for model weights

Runtime Exploits

The most common attack vector today. ML libraries (torch.load, pickle, safetensors) have had critical CVEs:

python

import torch
 
# Vulnerable — pickle serialization can execute arbitrary code
model = torch.load("model.pt")  # CVE-2023-XXXX

Safe alternatives:

Use safetensors format (no code execution risk)
Validate model files against a known hash
Load models in isolated containers

ML Bill of Materials

Just as software SBOMs list every dependency, an ML-SBOM should track:

json

{
  "model": "gpt-4o-fine-tuned-v2",
  "base_model": "gpt-4o (OpenAI)",
  "fine_tuning_data": ["support_tickets_2025.parquet"],
  "datasets": [
    {"name": "customer-faq-v3", "hash": "sha256-abc..."}
  ],
  "dependencies": [
    {"name": "transformers", "version": "4.45.0"},
    {"name": "tokenizers", "version": "0.20.0"}
  ],
  "deployment": {
    "container": "ml-inference@sha256:def...",
    "runtime": "onnxruntime 1.20.0"
  }
}

Generate this for every model you deploy, and treat unexpected changes as security incidents.

Practical Recommendations

Pin everything — model versions, base images, library versions
Sign and verify — GPG-sign model weights, verify on load
Scan before loading — use ModelScan or similar
Isolate inference — never run model loading in the same process as user-facing APIs
Monitor for drift — unexpected changes in model output may indicate compromise

The ML supply chain is real and largely unsecured. Start treating model weights the same way you treat database passwords: protect them, verify them, and know exactly where they came from.

stay in the loop

get notified when new articles drop. no spam, ever.

Prefer RSS? Subscribe via RSS →