How to Check if an npm Package Is Safe

Every npm install adds someone else's code to your project, and that code runs with the same permissions you have. Most packages are fine, but a small number are abandoned, buggy, or outright malicious. The goal of this tutorial is to give you a five-minute routine you can run on any npm package before you install it, so you catch obvious problems early. You do not need to be a security expert — just consistent.

Prerequisites

• Node.js and npm installed (node --version should print a version)
• A terminal
• The name of a package you are considering, for example left-pad

Step-by-step

1. Inspect the package metadata. Before installing anything, ask npm to describe the package. This shows the latest version, license, maintainers, and repository without downloading the code into your project:

npm view express

Look for a real repository link, a recognizable license (like MIT or Apache-2.0), and a version history that suggests active maintenance.

2. Check how recently it was updated. A package last published years ago is not automatically bad, but it may be abandoned and unlikely to receive security fixes. Compare the latest version date against how important the package is to you:

npm view express time.modified

3. Look at real-world usage. Popularity is not proof of safety, but a package with millions of weekly downloads has many more eyes on it than one with a handful. Check the download count on the npm website, and confirm the GitHub repository has issues, stars, and recent commits.

4. Watch for typosquatting. Attackers publish packages with names one character off from popular ones — reactt, expresss, lodahs. Read the name character by character and confirm it matches the package you actually intended. This single habit prevents a large share of npm supply-chain incidents.

5. Scan for known vulnerabilities. Once a package is a serious candidate, check whether it or its dependencies carry known CVEs. If it is already in a test project, npm audit gives a fast read:

npm audit

For a package you have not installed yet, a supply-chain scanner can evaluate it and its full dependency tree in one pass:

curl -sSfL https://get.safeguard.sh/install.sh | sh
safeguard scan --path .

6. Review the dependency count. A package that pulls in dozens of transitive dependencies expands your attack surface. Fewer, well-maintained dependencies are usually safer than a tower of tiny ones. You can see the tree with npm ls.

7. Read the install scripts. Malicious packages often hide in lifecycle scripts that run automatically on install. If you want to be cautious, install with scripts disabled and inspect first:

npm install express --ignore-scripts

How to know it worked

You have vetted a package successfully when you can say: it is actively maintained, it has a real repository and a clear license, the name is spelled exactly right, and a scan shows no unresolved critical vulnerabilities. If any of those fail, you either look for an alternative or accept the risk deliberately rather than by accident. The point is not zero risk — it is an informed decision.

Next steps

Doing this by hand for one package is a great habit. Doing it automatically for every package, on every commit, is where a platform earns its keep. Automated software composition analysis watches your whole dependency tree and re-checks it as new CVEs are disclosed. The Safeguard CLI lets you run the same checks locally and in continuous integration so a risky package never reaches your main branch. To go deeper on the ideas behind package trust, browse our concepts pages, and practice the full workflow in the Safeguard Academy.

Frequently Asked Questions

Is a package with millions of downloads automatically safe?

No, but popularity does help. High download counts mean more people are likely to notice and report problems, and well-known packages are usually maintained. However, popular packages have still been compromised through hijacked maintainer accounts, so you should always combine download numbers with a vulnerability scan rather than trusting them alone.

What is the difference between npm audit and a dedicated scanner?

npm audit checks your installed dependencies against npm's advisory database and is a great first line of defense. A dedicated supply-chain scanner typically covers more advisory sources, adds context like reachability and license risk, and works across ecosystems, not just npm. Use npm audit for a quick check and a scanner for a complete picture.

How do I spot a typosquatting package?

Read the exact name and compare it letter by letter to the official one, and confirm the repository URL points to the genuine project. Be suspicious of a brand-new package with very few downloads that shares a near-identical name with a popular one — that combination is a classic warning sign.

Should I worry about transitive dependencies I did not choose?

Yes. Most of the code in a typical project comes from transitive dependencies — the packages your packages depend on. A vulnerability three levels deep runs in your app just like your own code. This is exactly why scanning the full tree, not just your direct dependencies, matters.

Want every install checked automatically? Create a free account at app.safeguard.sh/register and keep learning at the Safeguard Academy.