Most package habits carry over to models: pin exact versions, verify hashes, record provenance, review changes. What differs is tooling. Models usually have no lockfile, no standard advisory feed and no automatic update pull request, so teams must build those habits by hand.
Habits that carry over
| Package habit | Model equivalent |
|---|---|
| Pin an exact version | Pin the full commit hash. The Hub's download guide requires the full length hash |
| Verify integrity hashes | Hash files and compare against a manifest |
| Prefer a trusted registry | Load from an internal store with approved copies |
| Review dependency changes in pull requests | Put the model revision in version controlled config |
| Remove unused dependencies | Retire models and clear caches |
| Read the license | Record the license tag and check use |
Where models differ
No lockfile by default. A package manager writes the resolved version and hash. A model loaded by name gets whatever the name points to. Without a pin, two builds a week apart can load different files.
Names can move. The Hub's documentation says a rename or transfer redirects the old URL. A package registry has its own rules; check each for how names behave.
Executable on load, sometimes. Python's pickle documentation warns that unpickling can run arbitrary code. Packages run code at install or import time. Models in some formats run code at load. In both cases the file is not just data.
Advisories are thinner. Package ecosystems have established vulnerability databases. For models, coverage is different and often missing, so expect to do more first hand review. A scanner that lists library vulnerabilities will not necessarily describe a model file. See does my dependency scanner cover ML libraries and model files.
Updates are not automated. Bots open pull requests for new package versions. For models, someone has to notice an upstream change, unless you set up a webhook. See how to get an alert when a model changes upstream.
What to build first
- A model inventory with source, hash and owner, since you cannot protect what you cannot list.
- A pin in config for every model load.
- A manifest of file hashes checked in CI.
- An upstream watch for models you rely on.
- A rule on file formats.
The libraries still matter
Models do not run alone. They run through libraries with their own versions and advisories. A vulnerable inference server is a risk whatever model it loads, and several posts in this series cover cases like that. Keeping the package side clean is the part you can already measure.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an inventory records for each package, then ask what the same record would hold for a model.
Safeguard's SBOM and dependency scanning cover the package side, with reachability analysis to show which findings matter. Run a free scan.
Quick check
Do models have lockfiles?
Not by default. Create one by pinning a full commit hash and keeping a hash manifest.
Can a package scanner vet a model file?
Do not assume so. Check what your tool says it covers.
Sources
- huggingface_hub documentation, Download files
- Hugging Face Hub documentation, Repository Settings
- Python documentation, pickle
Last reviewed: 19 October 2026.
