No. A popular package can still ship a vulnerability, lose a maintainer account, or be imitated by a lookalike name. Popularity is a reason a package is worth attacking, not a safety guarantee. Treat download counts as one signal among several, and verify the specifics before you add it.
Myth versus fact
| Myth | Fact |
|---|---|
| Millions of downloads means it was reviewed | Downloads measure use, not review |
| Many stars means it is maintained | Stars do not show recent commits or open security issues |
| If it were malicious, someone would have noticed | Registries do remove malware after reports, which means it exists first |
| A verified build link means the code is clean | Provenance shows where it was built, not that the code is harmless |
| A scoped, official-looking name is the real one | Always compare the exact name, publisher and repository |
What the registry itself says
The npm documentation on reporting malware states that npm Security has removed hundreds of malicious packages from the registry, and that for each report it confirms validity, removes the package, publishes a security placeholder and publishes an advisory. That process is reassuring, and it also confirms the point: malicious packages do appear, and removal follows discovery.
The npm provenance documentation is just as direct. When a package has established provenance, it does not guarantee the package has no malicious code. It gives a verifiable link to the source code and build instructions, which developers can audit to decide whether to trust it.
Signals worth checking instead
- Exact name and publisher. Typosquats rely on a hurried glance.
- Repository link and recent activity. Does the repo exist, match the package, and show recent maintenance?
- Number of maintainers. One person can be a single point of failure.
- Install scripts. Does the package run code at install time?
- Dependency footprint. What else comes along for the ride?
- Known advisories. Check before adding, not after.
None of these is a verdict. Together they take two minutes and catch the careless cases.
A first-week habit
Before every new dependency, answer in the pull request description: why this package, what alternatives you considered, who maintains it, and what it pulls in. If the answer is "everyone uses it", keep looking. For a template, see our twenty minute dependency review.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how knowing a package has an advisory differs from knowing it is exploitable in your code.
Quick check
Are small packages riskier than popular ones?
Not by size alone. Both can be risky. Judge maintenance, ownership, install behavior and what the package does.
Does an npm provenance badge mean I can skip review?
No. It links the package to its source and build, which helps you audit, but it does not certify the code.
Sources
Last reviewed: 19 October 2026.
