When you open a package's provenance on npmjs.com, npm checks that the linked source repository and commit still exist. If it cannot find them, it shows an error saying provenance can no longer be established. The docs say this can happen when a repository is deleted or made private. It does not by itself prove tampering.
What npm checks
Per the npm docs, whenever you access provenance information on npmjs.com, the linked source commit and repository are checked by npm. If either cannot be found, an error message appears at the top of the page and next to the provenance details. The point is to tell you that the claim "this package was built from that source" can no longer be verified by looking.
The provenance details normally list five items: the build environment, a link to the workflow run, the source commit, the build file, and a public ledger entry. The error means the links to that evidence stopped resolving.
Likely causes
| Cause | What it suggests |
|---|---|
| Repository deleted | Maintainer cleanup, account closure, or a takeover attempt |
| Repository made private | Maintainer decision, or the project moved |
| Repository renamed or transferred | Links may break until updated |
| Commit removed | History was rewritten |
The docs name the first two. The others are plausible, but I could not confirm them from the docs, so treat them as questions to ask, not conclusions.
What the signature still tells you
Provenance is signed by Sigstore and logged in a public transparency ledger. The ledger entry is a record that a build identity published that version at that time. That record does not disappear when a repository does, but without the repository you cannot inspect the code it points to.
Keep the main limit in mind. npm's own docs say established provenance does not guarantee a package has no malicious code. It gives a verifiable link to source and build instructions for you to audit.
A response routine
- Check whether the package is one you depend on directly, and in which projects. A lockfile search or an npm query helps. See npm query selectors.
- Look at the package's recent releases and publisher. A new version published after the repository vanished deserves extra scrutiny.
- Check the project's other channels for an announcement of a move or rename.
- Pin the version you already use, and hold off on upgrades until the source is explained.
- If you suspect compromise, report it. See how to report a malicious package.
- Decide whether to find an alternative, vendor the code after review, or accept the risk with a written reason.
Verify what you installed
Independent of the web page, the CLI check is:
npm audit signatures
The docs say it checks registry signatures and provenance attestations and returns an error if a package has missing or invalid ones. You need npm v9.5.0 or later and dependencies installed with npm install or npm ci. A package with no attestations at all is not an error in itself, since many packages never published any.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation keep a record of which versions of which packages each project resolves, so you can answer "where do we use this" in minutes, and continuous monitoring watches for advisories on them. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does a missing repository prove the package is malicious?
No. It means npm cannot establish provenance from the linked evidence. Deleted or private repositories are the documented causes, and many have innocent explanations. It is a reason to look closer.
Does a valid provenance badge mean a package is safe?
No. The npm docs say provenance does not guarantee a package has no malicious code. It links a package to its source and build for you to audit.
Sources
Last reviewed: 19 October 2026.
