No. Every ecosystem checks downloads differently, and some checks are off until you turn them on. pip verifies only if you supply hashes. Go checks every module against go.sum and a public checksum database. npm can verify registry signatures and provenance on request. None of them prove a package is safe, only that it is the one published.
What integrity checking proves
A hash check answers one question: is this file byte for byte the file I expected? It protects against tampering in transit and against a registry serving different content later. It does not tell you whether the original author was honest, whether the account was compromised, or whether the code has a vulnerability.
Keep that boundary in mind. Integrity is a floor, not a verdict.
How three ecosystems differ
| Ecosystem | Where the expected hash comes from | On by default? |
|---|---|---|
| pip | Hashes you write into the requirements file | No, activates when any hash is present |
| Go | go.sum, plus the public checksum database | Yes, on every download |
| npm | Registry signatures, checked by the audit signatures command | No, you run it |
pip
The pip docs describe hash-checking mode as protection against remote tampering and network corruption. It is all or nothing: giving a hash to any requirement activates it globally, every requirement needs a hash, and every dependency must be listed. Requirements must be pinned to an exact version, a URL or a path. sha256 is recommended, while md5, sha1 and sha224 are excluded. The hash fragment PyPI puts in download URLs does not count, because it comes from the same remote server.
Go
The Go reference says all module-aware commands verify that hashes in go.sum match the downloaded modules. If a hash is missing, Go consults the checksum database, unless the module path matches the private module settings. A mismatch is reported as a security error and the file is not installed in the module cache. The default checksum database is sum.golang.org.
A separate command, go mod verify, checks that modules already in the local cache have not been modified since download. It does not use go.sum for that comparison.
npm
The audit command can verify registry signatures of downloaded packages and also verify provenance attestations. It checks them against public keys published by the registry. The docs say only one signature algorithm, ecdsa-sha2-nistp256, is currently supported.
Setting a minimum across languages
You do not need the same mechanism, only the same promise. A workable minimum:
- Installs are locked, so the set of packages is fixed.
- Where the ecosystem supports hashes, they are recorded and checked in CI.
- Private module paths are configured explicitly, not left to default.
- Any switch that turns checking off, such as disabling the checksum database, needs a written reason.
The last item matters. In Go, setting the checksum database to off means it is not consulted. That is sometimes needed for private code, but it should be a decision, not an accident.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Does a matching hash mean a package is safe?
No. It means the file is what was published. A malicious package publishes a valid hash too.
Does pip check hashes automatically?
Only once at least one requirement has a hash, which activates hash-checking mode for everything. Otherwise it does not verify against recorded hashes.
Sources
Last reviewed: 19 October 2026.
