Before you install a package, spend two minutes on its registry page: confirm the exact name, see who owns it, check that the repository link is real and matches, look at release dates, see whether provenance is present, and scan the manifest for install scripts. Any mismatch is a reason to stop.
The two-minute checklist
- Name. Compare character by character with what you meant to install. Lookalike names are a standard trick.
- Owners. The page lists maintainers or owners. Is it a person, an organization, or several? Does it match what the project's README says?
- Repository link. Follow it. Does the repository exist, have real history, and mention the same package name?
- Release dates. A very recent first release of a well-known name is suspicious. A long gap followed by a new version deserves a diff.
- Provenance. On npm, packages built through a supported CI provider can carry a signed provenance attestation. You can check installed packages with
npm audit signatures, which reports verified registry signatures and attestations. - Install scripts. Open the manifest and look for preinstall, install or postinstall entries.
- License. Confirm one is declared and fits your policy.
What each check protects against
| Check | Attack it helps catch |
|---|---|
| Name | Typosquatting, lookalike packages |
| Owners | Unexpected publisher, handoff |
| Repository link | Package that does not match the claimed source |
| Release dates | Sudden takeover or revival |
| Provenance | Package built somewhere other than claimed source |
| Install scripts | Code that runs on install |
| License | Legal surprises |
Provenance details to know
The npm documentation says provenance links a package to its source code and build instructions, signed through Sigstore public good servers and logged in a public transparency ledger. For the link to work, the repository field in the manifest has to match the publishing source. It also says provenance does not guarantee the package has no malicious code. Treat a green mark as confirmation of origin, then judge the origin. For a case study, see valid provenance is not safe.
Install scripts
The npm scripts documentation lists preinstall, install, postinstall, prepare and related scripts as running during npm install, including global installs. That means code from the package or its dependencies can execute on your machine at install time. Our post on whether install scripts run for dependencies goes through what to review.
Make it a habit
Put the seven items in your pull request template for new dependencies. The few seconds per package add up to a durable control, and they feed straight into an adoption record.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Does a download count prove a package is legitimate?
No. Counts can be gamed or reflect a lookalike that spreads through copy and paste.
Is a missing provenance mark a red flag?
Not on its own. It is not available for every build setup. Treat it as one more reason to read the source.
Sources
Last reviewed: 19 October 2026.
