No. Signing shows a package came from a particular publisher and was not changed after signing. Provenance shows where and how it was built. Neither says the code is harmless. They make tampering and impersonation harder, and they give reviewers something to verify.
What each one proves
The Visual Studio Marketplace signs all extensions when they are published, and VS Code checks the signature on install to verify the integrity and source of the package. That protects against a package altered in transit or swapped by a mirror.
npm provenance goes a step further. Per the npm documentation, a provenance attestation links a package to its source code and build instructions in the build environment, so a consumer can check where and how it was built. Publish attestations are generated by the registry when an authorized user publishes. Packages published with provenance are signed using Sigstore public good servers and logged in a public transparency ledger. The same page says plainly that provenance does not guarantee a package has no malicious code. It gives a verifiable link to source and build instructions that you can audit and then decide whether to trust.
It also lists limits: publishing with provenance requires a supported cloud CI/CD provider with a cloud hosted runner, and the documentation names GitHub Actions and GitLab CI/CD for today.
Claims compared
| Question | Signature | Provenance |
|---|---|---|
| Was the file changed after publish? | Answers it | Partly |
| Who published it? | Yes | Yes, via the registry |
| Which source and build produced it? | No | Yes |
| Is the source code safe? | No | No |
| Was the publisher account hijacked? | No | Only partly visible |
A hijacked account that can publish can also sign. Provenance helps because a build that suddenly comes from an unexpected repository or pipeline stands out.
How a product team can use these signals
- Verify signatures on install and refuse unsigned packages for any production plugin channel.
- Capture provenance when it exists and store it with the plugin record.
- Alert on drift. A new source repository, a new workflow or a missing attestation on a plugin that used to have one deserves human review.
- Encourage publishers to build releases in a hosted pipeline from public source, and give them documentation to do so.
- Do not make signals into a pass. Keep permission review, scanning and sandboxing in place.
Protect the signing keys too
A signature is only as strong as the key behind it. Publisher accounts need multi factor authentication, and signing keys belong in a protected build environment, not on a developer laptop. A stolen key lets an attacker produce perfectly valid malicious releases. Short lived credentials, the approach Sigstore describes, reduce that exposure.
Quick check
If a plugin has provenance, can I skip review?
No. The npm documentation itself says provenance does not guarantee the absence of malicious code. It tells you where the package came from so you can decide what to review.
What if a plugin has no provenance at all?
That is common. Treat it as one lower confidence signal and rely more on permissions, scanning and monitoring until the publisher adds it.
Safeguard adds a layer that signatures do not: SBOM and dependency scanning for the libraries inside a package, and policies that gate on the result. The free scan is an easy trial.
Sources
Last reviewed: 19 October 2026.
