- 01Pulling a public model is supply-chain equivalent to executing a binary. Tokenizer code, custom inference code, and the weights themselves all carry attack surface.
- 02Real attacks observed in 2024–2025: tokenizer init code making outbound calls, weight backdoors triggered by specific tokens, fine-tunes that pass functional tests but degrade safety alignment.
- 03Minimum bar: internal model registry, pinned content hashes (no 'latest'), sandboxed pre-promotion testing, sigstore-signed artifacts, and a Model Bill of Materials per release.
- 04Reuse existing supply-chain primitives (signing, lifecycle, vulnerability tracking) — do not stand up an AI-only program. Adapt the artifact shape, keep the discipline.
Pulling a model from a public repository is, from a supply-chain perspective, equivalent to executing a binary. The model carries weights, tokenizer code, and often custom inference code. Each is an attack surface.
What 'good' looks like
- 01Internal model registry — no direct pulls from public registries in production
- 02Pinned versions and content hashes; no 'latest' tags
- 03Static scanning of tokenizer/inference code for known patterns
- 04Sandboxed testing environment before promotion
- 05Signed model artifacts using sigstore or equivalent
- 06SBOM-equivalent — Model Bill of Materials capturing weights, code, datasets
Real attacks we have seen
Custom tokenizer code making outbound calls during initialization. Model weights with subtle backdoors triggered by specific tokens. Fine-tunes that pass functional tests but degrade safety alignment. None of these were caught by traditional supply-chain tools because the tools do not understand model artifacts.
Closing the gap
Treat model artifacts as a new asset class. Build the registry, the scanner, the SBOM equivalent. Reuse the rest of your supply-chain tooling — signing, lifecycle, vulnerability tracking — adapted to the new artifact shape.