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; especially relevant for anything pulled from a public model hub or package registry, where provenance is self-reported rather than independently verified.

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. An SBOM-style inventory is also only as current as the last time someone regenerated it, so it decays quietly if it isn't tied to the build pipeline. Complements, rather than replaces, behavioural testing like data/model poisoning detection below.

Cite this