No. npm provenance links a package to its source and build, which is useful evidence, but a malicious publisher can attach provenance to a malicious package. It helps you judge a package. It does not stop a hallucinated name from being registered or installed.
What provenance is
The npm documentation says provenance statements publicly show where a package was built and who published it. There are two parts: a provenance attestation linking the package to source code and build instructions, and a publish attestation generated by the registry, signed through Sigstore and recorded in a public transparency ledger. You can check signatures and attestations on your installed packages with npm audit signatures.
Myth: provenance means safe
Fact: The same page says a package with provenance does not guarantee the package has no malicious code. It gives you a verifiable link you can audit. An attacker who builds and publishes from a public repository can have provenance too.
Myth: no provenance means malicious
Fact: Many legitimate packages have no provenance. Publishing it requires a supported CI provider, a recent npm version and configuration. Missing provenance is a reason for a closer look, not proof of a problem.
What it does help with
- Tracing a suspicious package to its source. If the linked repository does not match the claimed project, that is a red flag.
- Spotting a change in how a package is published. A package that always had provenance and suddenly does not deserves attention.
- Raising the cost for lazy attackers. Verifiable history is harder to fake convincingly.
Where slopsquatting sits
Slopsquatting relies on a model inventing a plausible package name that an attacker then registers. A study of 16 code generation models reported at least 5.2% hallucinated packages for commercial models and 21.7% for open source models. The attacker's package arrives with a brand new name and no history, and can still publish with provenance.
So the useful signals are age, publisher history and whether the package was already in your project, not only the presence of an attestation.
A layered answer
- Verify the package exists and has history.
- Check provenance as supporting evidence.
- Read install scripts.
- Lock versions and review lockfile changes.
A practical rule
Use provenance as a tie breaker, not a gate. Between two packages that otherwise look equal, prefer the one whose attestation points to a real, active repository that matches the project. Never let the badge replace reading the install scripts and checking the first release date. A signal that can be satisfied by an attacker should only ever add confidence, never end the review.
Quick check
Should I require provenance for every dependency?
Not as a hard rule today, since many valid packages lack it. Consider requiring it for high risk dependencies and treating its absence as a prompt for review.
Sources
Last reviewed: 19 October 2026.
