To check if an npm package is safe, confirm the exact name, look at who publishes it and where its source lives, read its install scripts, verify provenance with npm audit signatures, and check known advisories. No single check proves safety, so use several before you run npm install.
Key takeaways
- Most risk arrives at install time, because lifecycle scripts run automatically.
- Name, publisher and repository checks take two minutes and catch lookalikes.
npm auditfinds known vulnerabilities only. A new malicious package has no advisory yet.- Provenance proves where a package was built, not that its code is harmless.
Why does installing a package carry risk?
Because npm runs lifecycle scripts when you install. The npm documentation lists preinstall, install and postinstall among the scripts that run on npm install, and they run from the scripts of the package being installed. Code in those scripts executes with your permissions before you have read anything.
That is also true for transitive dependencies you never chose directly.
Check 1: Is the name exactly right?
Compare the name letter by letter with the one in the project's own documentation. Lookalike names, swapped letters and extra hyphens are the classic trick. Our typosquatting explainer shows the patterns.
Copy the install command from the official README, not from a search result or a chat answer.
Check 2: Who publishes it?
Open the package page on npmjs.com and look at the maintainers, the publish history and the number of versions. A package with one release made last week, a single unknown maintainer and a name close to a famous one deserves suspicion. npm owner ls lists the maintainers from the command line.
Check 3: Does the repository match the package?
The package page links a repository. Open it and confirm it is the real project, with real history and activity. Then check the published package contents against it. A repository field that points to a different project, or to nothing, is a warning.
Check 4: What do the install scripts do?
Read the scripts section of the package's package.json. If you see preinstall, install or postinstall, read what they call. The npm documentation advises against install or preinstall unless compilation must happen on the target architecture, so a plain library with a postinstall script that fetches something is unusual.
To go further, install with the ignore-scripts option set to true first, then inspect. Setting ignore-scripts to true by default is a common team policy. Some native packages need scripts, so allow those on purpose.
Check 5: Does it have provenance?
Run npm audit signatures. It verifies registry signatures and provenance attestations of downloaded packages, and reports how many of each were verified. Provenance links a package to its source code and build instructions through a public transparency ledger.
The docs are clear about the limit: provenance does not mean a package is free of malicious code. It gives you something to audit.
Check 6: Are there known vulnerabilities or reports?
Run npm audit to compare your dependency tree with known advisories. It sends package names and versions to your registry and reports what it finds. For malicious packages, check a registry that tracks them. The Gold registry lists packages with CVEs, CISA KEV status and malicious package flags.
You can also check a package.json or lockfile for free at gold.safeguard.sh/scan. It needs no login, runs in your browser, keeps the file on your machine and covers up to 100 dependencies.
Check 7: Do you need it at all?
Every dependency adds code you do not control. If the package replaces ten lines you could write, write them. Fewer dependencies mean fewer chances for one to go wrong.
Quick checklist
- Name matches official docs exactly
- Maintainers and release history look normal
- Repository is real and matches the package
- Install scripts read and understood
- Provenance checked with
npm audit signatures - Advisories and malicious package lists checked
- Dependency is actually needed
What if I already installed something suspicious?
Stop and treat the machine as exposed. Remove the package, rotate any token or secret the machine could reach, and rebuild from a clean environment. Then report it. The npm documentation says that for malware reports, npm Security confirms the report, removes the package, publishes a security placeholder and publishes an advisory.
Frequently asked questions
Does npm audit tell me if a package is malicious?
Not reliably. It reports known vulnerabilities from advisories, and a newly published malicious package may have none yet.
Is a package with many downloads safe?
Not automatically. Popularity helps, but popular packages can be hijacked and lookalike names can inflate their own numbers.
Should I disable install scripts?
It is a common safe default. Set ignore-scripts to true and allow scripts only for packages that need native builds.
What does npm provenance show?
It shows where and how a package was built, signed through Sigstore and recorded in a public ledger. It does not show the code is benign.
How do I report a malicious package?
Use the Report malware button on the package page and include the package name, versions and evidence such as code examples.
Sources
- npm Docs: scripts
- npm Docs: npm audit
- npm Docs: generating provenance statements
- npm Docs: reporting malware in an npm package
- Safeguard Gold dependency scan
Last reviewed: 19 October 2026.
