Yes. A package on a registry is an upload, and a registry does not require its contents to match the public repository. Differences can come from a compromised build, a leaked publishing credential or a deliberate trick. Provenance and rebuild checks can reveal a mismatch, but only if you look.
Why a mismatch is possible
Most registries accept what the publisher sends. The repository is where people read and review code. The package is what gets installed. Nothing in the install path forces the two to agree unless the producer builds in a controlled way and publishes evidence.
The SLSA overview describes two relevant cases. In one, an attacker modified build infrastructure so it used source files that did not match source control. In another, leaked credentials were used to upload a malicious artifact to a storage bucket that users download from directly. In both, the repository looked fine.
What differences look like
- Files in the package that do not exist in the repository, such as extra scripts or minified blobs.
- A package version with no matching tag or release in the repository.
- A new install script added only in the published manifest.
- A different dependency list in the published metadata than in the repository.
How to check
- List the contents of the package and compare to the tagged source for that version. For a package you depend on heavily, do it once per major change.
- Look for provenance. npm's documentation says provenance publicly establishes where a package was built and links to the source code and build instructions, signed through Sigstore and recorded in a public transparency ledger.
- Check that the provenance points to the repository you expect, and that the workflow is the one the maintainers use.
- For critical packages, rebuild from source in a clean environment and compare outputs where builds are reproducible.
What provenance cannot tell you
The npm documentation is direct about this: provenance does not guarantee a package contains no malicious code. It gives you a verifiable link back to the source and build instructions so that you can audit and decide. If the source repository itself carries a bad commit, the provenance will correctly point to it.
A practical rule
Spend this effort where the exposure is highest. A package that runs in your build or at install time with broad access deserves a check. A small, well understood development helper may not. Our post on build provenance gives more background.
Where Safeguard fits
Safeguard's SBOM and dependency scanning record the exact versions you consume, which gives you something concrete to compare. Continuous monitoring helps you notice when a version changes.
Quick check
Does a verified publisher badge mean the package matches the repository?
Not necessarily. A badge speaks to identity, not to whether each artifact matches its source.
Do I need to check every package?
No. Prioritise packages that run at install time or hold broad access, and automate checks where you can.
Sources
Last reviewed: 19 October 2026.
