m00dy.sh
Notebook/2026-08-19
2026-08-19 / ML security · supply chain · methodology

Treat a Model Download Like a Software Supply-Chain Decision

A from_pretrained() call is a download, a parse, and an execution decision wrapped in one convenient API. A reviewable workflow: pin the revision, approve the whole snapshot, read scan results literally, make the first load disposable, and promote the exact object you tested.

August 19, 2026 · 5 min read
ml-securitysupply-chainformatsmethodology
on this page

Suppose a developer finds a model on a public hub and tries it with from_pretrained(). The call looks like a download followed by an ordinary library operation. By the time it returns, the client may have fetched weights, configuration, tokenizer files, templates, and Python code. Those files are now being interpreted by a particular version of a loader inside a process that may have credentials and network access.

The security decision has already happened. It was simply hidden inside a convenient API.

A safer workflow puts a review step between the public repository and the environment that will use it. Download an exact snapshot, inspect what the runtime will consume, test it somewhere disposable, and only then copy the approved snapshot into internal storage.

Approve the snapshot, not one weight file

The largest file in a model repository is usually the weights, so it attracts most of the attention. The loader may use many smaller files too.

A typical repository can contain all of the following.

  • model weights
  • architecture and generation settings
  • tokenizer rules
  • a chat template
  • adapters
  • custom Python code

Any of these can change what runs or how the model behaves. Hashing model.safetensors does not tell you whether tokenizer_config.json or a Python module changed beside it.

The object to approve is the complete set of files the production loader will use. If the loader fetches another file later, that file was never part of the approval.

Freeze the version before inspecting it

A repository name is not a version. Neither is main.

Hugging Face download functions accept a full commit hash through the revision parameter. Pinning that hash gives the review a stable object.

from huggingface_hub import snapshot_download

snapshot_download(
    repo_id="publisher/model-name",
    revision="FULL_COMMIT_HASH",
)

Record the repository, full revision, file list, and a digest for every file you keep. A signature can add evidence about who produced a commit. The digests show whether the bytes later changed. Neither one tells you that the contents are safe, but both tell you exactly what was reviewed.

Without a pinned revision, a later startup can receive different files under the same repository name. The original scan and test results no longer describe what is running.

Find out what the loader can execute

The file format matters because different formats give the loader different jobs.

Pickle can cause Python functions to run while it reconstructs objects. Loading an untrusted pickle is therefore an execution decision. Safetensors stores tensor data without pickle’s load-time execution mechanism, which removes that particular risk.

The rest of the repository still matters. Safetensors weights can sit beside custom Python code. Transformers requires trust_remote_code=True for some custom models and warns that this can execute code from the repository. Its own documentation recommends pinning a specific revision when that option is used.

Before the first load, answer three concrete questions.

  1. Which files will the loader open?
  2. Which of those files can be interpreted as code or instructions?
  3. Which loader and dependency versions will perform that interpretation?

If the team cannot answer them, the model is not ready for a privileged environment.

Read scan results literally

Hubs and local tools provide useful checks. Hugging Face documents malware, pickle, secrets, and third-party scanning. ModelScan can inspect several common serialization formats without loading them through the normal framework.

A scan result only covers the files and formats the scanner understood. It does not establish that an unsupported file is harmless. It also does not establish that the model’s learned behavior is benign.

Keep three outcomes in the admission record.

  • examined and passed
  • examined and failed
  • not examined

The third outcome is important. ModelScan, for example, has a distinct exit status for a run that received no supported files and can report which files it skipped. Treating that result as clean would erase the most useful fact the tool reported.

Make the first load disposable

Static review cannot predict everything a loader or model will do. The first execution should therefore happen in an environment that is safe to lose.

Do not begin on a developer laptop with cloud credentials. Do not give the test process production secrets, unrestricted network access, shared writable storage, or powerful external tools. Observe file access, subprocess creation, dynamic imports, and connection attempts during loading and a small set of representative requests.

This test does not prove that the model has no hidden behavior. It checks a more basic assumption. It shows whether the snapshot and loader behave the way the team expects before either receives production authority.

The permissions should come from the application’s needs. A model used for offline classification probably needs no network access. An agent that calls an external service may need one destination and one credential, not the ambient permissions of the process that launched it.

Promote the exact object you tested

Once the snapshot passes review, copy it into controlled internal storage. Deploy it by internal identity and digest rather than resolving the public repository again at startup.

Keep the approval record beside it.

  • upstream repository and full commit hash
  • complete file manifest and digests
  • loader and dependency versions
  • scan tools, versions, and skipped files
  • first-load observations
  • approved permissions and remaining exceptions
  • reviewer and date

An upstream update starts a new review. The publisher may have fixed an important bug, changed a template, replaced the tokenizer, or added new code. Automatic promotion would treat all of those changes as equivalent even though they alter different parts of the system.

A policy that fits on one page

Most teams do not need a new platform to begin. They need a rule that prevents a public model from moving directly into production.

  1. Choose a known source and pin a full revision.
  2. Download the complete snapshot and record every file.
  3. Prefer tensor-only weights and review any executable loading path.
  4. Scan the formats the tools support and preserve the skipped list.
  5. Perform the first load without production credentials or open network access.
  6. Copy the approved snapshot into internal storage.
  7. Repeat the review whenever the snapshot, loader, or permissions change.

None of these steps proves that a model is safe in every possible use. Together they establish something more practical. The team knows which bytes it approved, what software interpreted them, and what the resulting process was allowed to reach.

That is enough to turn a model download from an implicit trust decision into a reviewable one.

References

Back to notebook