12. The ML supply chain and MLOps

Models and datasets are dependencies like any library, except they are harder to inspect, sometimes execute code when loaded, and are usually pulled from public hubs with weak provenance. Securing the ML supply chain means knowing exactly what you load, from whom, and proving it has not changed.

Model files can be programs

Python’s pickle format can instruct the loader to call arbitrary functions, so loading a pickle is running code (Part 2). Many PyTorch checkpoints have historically been pickles. Recent PyTorch versions default to a restricted “weights only” loading mode, and a 2025 vulnerability showed that even this safeguard could be bypassed in older versions. Keep the framework updated, and do not rely on one safeguard.

Other formats with similar risks: joblib files (pickle underneath), NumPy arrays loaded with pickle allowed, Keras models with embedded Python layers, and custom operators in some exchange formats. Native runtimes that parse model files have also had memory-safety bugs.

The safer default is safetensors: raw tensors plus a small JSON header, with no code path at load time.

On model hubs, the flag trust_remote_code=True downloads and runs Python code from the model’s repository. That is equivalent to installing an unknown package. Malicious models have been found on public hubs. Hubs scan uploads, but scanners can be evaded.

Rule of thumb: treat every model download as untrusted code execution, unless the format is data-only and the loader is current.

Provenance: where did this come from?

For every model and dataset, you should be able to answer:

• Who published it? Is the organization verified? Is the name a look-alike of a famous model?
• Which exact version? Pin to a commit hash, not a branch name like main, which can change under you.
• Has it been modified? Verify hashes or signatures before loading. The OpenSSF model-signing project, built on Sigstore, signs model files for exactly this.
• What is in it? Record it in an AIBOM (AI bill of materials; CycloneDX supports ML components): models, datasets, versions, licenses, sources. Model cards and datasheets document intended use and known limits.
• What data trained it? Track lineage, licenses, consent and personal data, and verify the hashes of downloaded data (Part 9’s poisoning attacks exploit exactly this gap).

The same discipline applies to code dependencies suggested by AI tools. Check that every package exists, is the one you meant, and is maintained, because attackers register names that models tend to hallucinate.

Fine-tuning and adapters

LoRA adapters and fine-tuned checkpoints are artifacts too. They can carry backdoors or quietly remove safety behaviour (Part 9). If your product lets customers fine-tune, you inherit the job of screening their training data.

The MLOps infrastructure

ML tooling was often built for researchers on trusted networks. Put into production, it becomes an attack surface:

• Notebook servers exposed without authentication; notebooks holding credentials, with sensitive data saved in output cells.
• Experiment trackers and model registries deployed without authentication “because it’s internal”. Write access to the registry means the power to swap the production model.
• Distributed compute frameworks whose job APIs run code by design. In 2024, attackers exploited internet-exposed clusters of one such framework at scale, for cryptomining and credential theft.
• Inference servers reachable from the internet without authentication, or running outdated parsers.
• GPU hosts - drivers are privileged code, and research has shown that on some hardware, data in GPU memory can leak between processes.
• Training pipelines with broad cloud permissions and data pulled from external sources.
• Secrets sitting in notebooks, config files, container images and experiment logs.

Protecting model weights

Weights embody enormous training cost, and stolen weights can be used without any of the developer’s safeguards. A 2024 RAND report, “Securing AI Model Weights”, identified dozens of distinct attack vectors and defined five security levels, from stopping amateur attackers up to resisting top-tier state operations. Typical controls: very few people with access; no weights on laptops; encryption with tightly controlled keys; egress monitoring (weights are large, so bulk copies are noticeable); confidential computing; insider-threat programs; and output limits that make distillation harder.

A checklist for your own pipelines

• Production loads only data-only formats such as safetensors; pickle is banned or sandboxed.
• trust_remote_code is off unless that code was reviewed and pinned.
• Models and datasets are pinned by hash or revision and mirrored internally.
• Signatures or hashes are verified before deployment.
• An AIBOM exists for every deployed model.
• Write access to the model registry and training data is restricted and logged.
• Notebooks, dashboards, trackers and model servers sit behind authentication on a private network.
• Training jobs run with least-privilege identities, and secrets come from a secrets manager.
• Every deployed model has a tested rollback path.

Questions to ask

• Which model and data files do we load, in which formats, and can any of them run code?
• Who published each artifact, which exact revision did we pin, and how do we verify it is unchanged?
• Who can write to the model registry or the training data, and is that logged?
• Which ML tools are reachable over the network without authentication?
• Where do the weights live, who can copy them, and would we notice?
• Could we produce an AIBOM for a deployed model today?