If a registry or mirror is compromised, it can serve a package that differs from what the author published. You can still detect many cases by checking hashes you recorded earlier and provenance signed outside the registry. You cannot detect them if you simply trust whatever the registry returns.
Why this is a distinct entry point
Most advice assumes the registry is honest and the publisher is the weak link. A compromised registry or a rogue mirror reverses that: the author did nothing wrong, but what you download has changed.
The SLSA threats overview lists this as its own link in the chain, compromise of the package registry. Its example is a researcher who ran mirrors for several popular registries, showing that such mirrors could have served malicious packages. The overview says provenance of the artifacts would have shown they were not built as expected or from the expected source repository.
What helps
- Recorded hashes. If your lockfile or requirements file stores a hash for each package, a changed file fails the install. Pip's secure installs guide describes hash-checking mode, enabled with the require-hashes option, as protection against remote tampering and network issues. It also notes the mode is all or nothing: specifying a hash for any requirement activates it globally.
- Provenance checked against a separate trust root. npm's documentation says provenance is signed through Sigstore and logged in a public transparency ledger, which it describes as a way to detect tampering attempts if a registry were compromised.
- Your own mirror with controls. A mirror you operate narrows who can alter content, though you then own its security.
- Source only installs for critical packages. Pip's guide also mentions disallowing source distributions with the only-binary option for secure installs, so you control what runs.
What does not help
- Trusting the version number. A tampered file can keep the same number.
- Trusting the download count or popularity.
- A scan of a package that was tampered with before you first fetched it, if you never recorded a hash from a trusted moment.
A realistic position
You probably cannot verify everything. A reasonable stance is layered:
| Layer | Check |
|---|---|
| Everyday packages | Lockfiles with hashes |
| Critical packages | Provenance plus a spot rebuild |
| Build infrastructure | Controlled mirror and network rules |
| Response | A plan to rebuild from clean sources |
When the first download is the problem
Hash locking protects against later changes. If the first copy you locked was already bad, the hash simply preserves the bad copy. That is why provenance and review of new dependencies matter at the moment of adoption.
Where Safeguard fits
Safeguard's SBOM and dependency scanning help you keep a record of exact components, and continuous monitoring flags later changes. Choosing and operating a mirror remains an infrastructure decision for your team.
Quick check
Do lockfile hashes fully solve this?
They stop later swaps of a locked file. They do not help if the file was already tampered with when you first locked it.
Is this a common problem?
The SLSA overview treats it as a real class of threat. How often it occurs is not something this post claims.
Sources
Last reviewed: 19 October 2026.
