Model & data supply-chain verification

How it works

A model that passes every behavioural eval can still carry a compromised dependency: a base checkpoint of unclear provenance, a fine-tuning or embedding dataset scraped from an untrusted source, a plugin or LoRA adapter pulled from a public registry, or an outdated package with a known vulnerability. Supply-chain verification checks the paper trail rather than the behaviour — model cards and licenses against what's actually deployed, hashes and version pins against what was reviewed, SBOM-style inventories of every model and dataset dependency, and a scan for known-vulnerable packages in the serving stack. It re-runs whenever any link in that chain changes, not just at initial adoption.

When to use it

Before adopting a third-party model, fine-tune, plugin, or pretrained embedding component; whenever the build pipeline pulls in a new dependency; on a recurring cadence for anything already in production.

Limitations

Provenance metadata is only as trustworthy as what upstream publishes, and a poisoned base model can pass every capability test while carrying a dormant backdoor triggered later — this checks the chain of custody, not the payload. Complements, rather than replaces, behavioural testing like data/model poisoning detection below.

Cite this