Yes, as a final gate. In hash-checking mode, pip refuses to install any package whose file hash is not listed in your requirements file. That means whatever your intake process approved is exactly what gets installed. It proves the file matches the record, not that the file is safe.
What the pip documentation describes
The pip secure installs guide describes hash-checking mode. In it, pip requires every package to have a hash recorded locally and compares the downloaded file against it. The guide notes that a hash which originates remotely is not a useful guard against tampering, and does not satisfy the demand that every package have a local hash. It also says hash-checking mode works with pip download and pip wheel, and warns not to undo the work by installing your own project through deprecated direct setuptools interfaces.
Where it fits in intake
Intake decides what to allow. Hash checking enforces that decision at install time.
- A package version passes review and scans.
- The approved file's hash is written into the requirements file.
- Every later install, in CI or in a container build, must match that hash.
- If the registry or the network serves a different file for the same version, the install fails.
That last point is what makes it a strong gate. A mirror that was tampered with, or an upstream file that was replaced, is caught at the point of use.
Using it well
- Generate hashes from the approved artifact. Take them from the file in your mirror after review, not from a page that describes the file.
- Hash every dependency, including transitive ones. Hash-checking mode expects each package to have a hash, so the requirements file must be complete.
- Pin exact versions. Hashes apply to specific files, so version ranges do not work with this mode.
- Record hashes for each platform you build on. Binary wheels differ by platform, so list the files you actually install.
- Regenerate through intake. Updating a version means updating hashes through the normal review process, not editing the file by hand.
What it does not do
| Question | Answered by hashes? |
|---|---|
| Is the file the one we reviewed? | Yes |
| Is the file free of malware? | No, only if the review caught it |
| Is the version free of known vulnerabilities? | No |
| Did a maintainer account get compromised before we reviewed? | No |
| Is the package still maintained? | No |
Hashes pair with scanning, source checks and holding periods. They are the lock on the door, not the inspection of who walks through.
Operational tips
- Make a CI check that fails if a requirements file contains an entry without a hash.
- Keep requirements files generated, not hand edited, so the format stays consistent.
- When a hash mismatch occurs, treat it as a signal and investigate before overriding.
Where Safeguard fits
Safeguard's dependency scanning and gates can check the packages you approved before they are used, and SBOM output records what each build contained. See an example with the free scan.
Quick check
Do hashes protect against a malicious but approved package?
No. They only prove the file matches what you recorded. The review has to catch the problem first.
Can I use hash checking with version ranges?
No. Pin exact versions, because each hash belongs to a specific file.
Sources
Last reviewed: 19 October 2026.
