ML Supply Chain Security intermediate 7 min read 12 flashcards

Vetting Third-Party Models and Datasets

A practical intake process for an artefact you did not produce, what each check can and cannot establish, and how to size the effort to the deployment's exposure.

Most models in production are derived from something the organisation did not train, and most datasets contain something it did not collect. Deciding whether to take a dependency on an external artefact is a recurring judgement, and the useful version is a process sized to exposure rather than a checklist applied uniformly.

What to check, and what each check settles

Identity and pinning. Which repository, which revision, which file hashes. This settles reproducibility and tamper-evidence and nothing else. It is cheap, it is the precondition for every later question, and it is the step most often skipped in favour of a bare model name.

Format. Safetensors rather than pickle, and remote code execution disabled unless there is a specific reason. This settles load-time code execution and says nothing about the model's behaviour.

Licence. The licence on the weights, the licence on the training data where stated, and any use restrictions. Derived models inherit constraints, and a chain of three derivations frequently ends with a team unaware of a restriction two steps back. This is the check with the highest ratio of legal exposure to effort.

Provenance claims. What the publisher says about training data, base model, and evaluation. This is a claim rather than evidence, and its value is that a publisher who documents nothing has told you something.

Behavioural evaluation on your own data. Held-out evaluation for quality, plus behavioural probes for the failure modes relevant to your application. This is the only check that establishes anything about how the artefact will behave for you, and benchmark scores from the publisher do not substitute for it.

Backdoor probing where exposure warrants: trigger reconstruction for classifiers, and for language models, evaluation on inputs designed around the deployment's sensitive decisions. This is expensive, incomplete, and worth doing where a compromise would be severe.

Sizing the effort

The reasonable scaling is by what a compromise would reach. A model summarising public documents in an internal tool warrants identity, format, licence and quality evaluation. A model in a decision path with regulatory exposure, or one with tool access in an agent, warrants the full set plus isolation of its runtime and monitoring of its outputs.

Uniform process across both produces either a bottleneck nobody follows or a rubber stamp, and the second is more common.

When it breaks

Popularity is treated as vetting. Download counts and stars measure adoption, not scrutiny, and a widely used artefact whose provenance nobody checked is widely used and unchecked. The correlation between popularity and safety is real and weak, and it is doing a lot of unexamined work in most intake decisions.

Datasets get less scrutiny than models and deserve more. A dataset's influence persists into every model trained on it and into every model derived from those, so a contaminated or licence-restricted dataset has a wider blast radius than a single model artefact.

Re-vetting on update is forgotten. Pinning to a revision means an upgrade is a new intake decision, and treating a version bump as maintenance rather than as a dependency change is how a vetted artefact becomes an unvetted one without any decision being made.

The chain is only as vetted as its weakest link. A carefully checked fine-tune of an unvetted base model has inherited everything the base model carried. Vetting has to reach the root of the derivation chain or stop explicitly at a named point, and recording where it stopped is what makes the residual risk visible.

Check yourself

12 flashcards for this concept

Click a card to reveal the answer.

Drill the whole track