Every developer has done it. You need a rate limiter, a date-parsing helper, or a slick charting library, so you run npm install, watch the terminal scroll, and move on. Twenty minutes later that one package has quietly pulled in 140 transitive dependencies, three of which haven't been updated since 2019, one of which just changed maintainers last month. You have no idea who any of those people are.
Here's the uncomfortable statistic: the 2024 Sonatype State of the Software Supply Chain report found that malicious open-source packages more than doubled year over year, with over 512,000 malicious packages logged across public registries. A separate study of the npm ecosystem estimated that the average project depends, directly or indirectly, on code from roughly 80 different maintainers. You are trusting all 80 of them with your production environment.
Open source is still the right default. It powers nearly everything you ship, and you should keep using it. But "free to download" is not the same as "safe to trust." This article walks through a repeatable process to vet open-source software before it touches your stack, with real checks, real numbers, and a scoring framework you can apply in an afternoon.
Key Takeaways
- Vetting open-source software is a supply-chain decision, not a feature decision. Judge the project, the maintainers, and the dependency tree, not just the README.
- Six signals matter most: maintenance cadence, maintainer diversity, security response history, license clarity, dependency footprint, and community trust.
- Run automated tooling (
npm audit,osv-scanner, Socket, Snyk) and a manual read of recent commits. Neither catches what the other misses.- A package with 40,000 stars and one exhausted solo maintainer can be riskier than a smaller project backed by a funded team.
- Pin versions, use lockfiles, and re-vet on every major upgrade. Vetting once is not vetting.
- For anything touching auth, payments, or user data, buy or build with vendor accountability instead of trusting an anonymous repo.
What "Vetting" Actually Means (and Why Star Counts Lie)
Vetting open-source software means evaluating the total risk of adding a dependency: the code quality, the humans behind it, the license terms, and the blast radius if it fails or turns hostile. It is closer to a background check than a product review.
Most people substitute GitHub stars for real diligence. Stars measure popularity at a moment in time. They do not measure whether the project is maintained, whether its security disclosures are handled, or whether the current maintainer is the same person who earned those stars three years ago.
The 2021 ua-parser-js incident is the cautionary tale. A package with tens of millions of weekly downloads had its maintainer's npm account compromised, and attackers pushed a version that installed a cryptominer and a password stealer. Popularity did not protect anyone. It just widened the blast radius.
The three layers you're really evaluating
- The code: Is it readable, tested, and free of obvious footguns?
- The project: Is it actively maintained by people who respond to security reports?
- The supply chain: What does it pull in, and can any of those transitive packages hurt you?
The Six Signals That Predict Whether a Dependency Will Burn You
Over years of adding, removing, and occasionally regretting dependencies, I've narrowed the useful signals down to six. Score each from 0 to 5 and you get a fast, defensible read.
1. Maintenance cadence
Open the commit history. A healthy project has commits within the last 60 to 90 days and a steady rhythm, not a two-year gap followed by a panicked flurry. Check whether issues get responses or pile up unread. A repo with 400 open issues and no maintainer replies in six months is effectively abandoned.
2. Maintainer diversity (the bus factor)
If one person has authored 98% of commits and holds the only publish key, the bus factor is one. That is a single point of failure for both burnout and account compromise. Prefer projects with 3+ active maintainers or a funded organization behind them.
3. Security response history
Search the repo for a SECURITY.md file and a history of published advisories. Counterintuitively, a project with a few disclosed and promptly patched CVEs is often safer than one with zero, because it means someone is watching and responding.
4. License clarity
Confirm the license file exists and matches what the README claims. MIT, Apache 2.0, and BSD are permissive and low-risk. GPL and AGPL carry copyleft obligations that can affect proprietary code. "No license" means all rights reserved and you legally cannot use it.
5. Dependency footprint
Run npm ls or check the dependency graph. A utility that pulls in 200 transitive packages to format a date is a liability. Fewer, well-known dependencies mean a smaller attack surface.
6. Community trust signals
Look for corporate backers, sponsorship, presence in major distributions, and how the maintainers communicate. A tool used inside large organizations has usually already been vetted by security teams more paranoid than you.
A Worked Example: Vetting a Charting Library in 30 Minutes
Say your team needs a charting library and you've shortlisted a candidate: quick-charts, 12,400 GitHub stars, 180,000 weekly npm downloads. Looks great on the surface. Here's the 30-minute vet.
- Minutes 0–5, cadence check. Last commit was 14 months ago. 210 open issues, last maintainer reply 8 months ago. Score: 1/5.
- Minutes 5–10, maintainer check. One maintainer, 96% of commits, sole publish access. Bus factor of one. Score: 1/5.
- Minutes 10–15, security check. No
SECURITY.md. One open vulnerability report from 5 months ago, still unaddressed. Score: 1/5. - Minutes 15–18, license check. Clean MIT license, matches package.json. Score: 5/5.
- Minutes 18–25, footprint check. Running
npm lsreveals 47 transitive dependencies, two of which are also unmaintained. Score: 2/5. - Minutes 25–30, scan.
osv-scannerflags one high-severity advisory in a nested dependency. Score: 2/5.
Average score: 2.0 out of 5. Those 12,400 stars represented a project that was hot in 2022 and quietly abandoned since. Meanwhile a smaller alternative with 4,000 stars, three active maintainers, a security policy, and 6 total dependencies would have scored around 4.3. The star count told the opposite of the truth.
Tools That Automate the Grind
Manual review catches judgment calls; automation catches known-bad code at scale. Use both. Here's how the common options compare.
| Tool | Best for | Detects supply-chain attacks? | Cost | Ease of use |
|---|---|---|---|---|
npm audit |
Known CVEs in npm deps | No (only known advisories) | Free, built in | Very easy |
| osv-scanner (Google) | Multi-ecosystem CVE scanning | Partial | Free, open source | Easy |
| Socket.dev | Behavioral / install-script risk | Yes (real strength) | Free tier + paid | Moderate |
| Snyk | Enterprise dep + license scanning | Partial | Free tier + paid | Moderate |
| Dependabot | Automated update PRs | No | Free (GitHub) | Very easy |
My default stack: osv-scanner in CI for the CVE net, Socket for behavioral analysis (it flags packages that add install scripts, network access, or filesystem reads between versions), and Dependabot to keep everything current. If you're already running AI in your workflow, be aware that generated code often suggests outdated or hallucinated packages. We covered that failure mode in why AI-generated code has 70% more bugs and how to fix it.
Reading the Repo Like a Detective
Automated scanners are blind to intent. A human reading the actual code catches the subtle stuff.
What to open first
- The install scripts. Check
package.jsonforpreinstall,postinstall, orpreparehooks. Legitimate libraries rarely need to run arbitrary code at install time. This is the number-one supply-chain attack vector. - Recent commits and releases. Read the last 10 commits. Do the diffs match the release notes? Sudden obfuscated or minified additions in a source repo are a red flag.
- The maintainer's other activity. A maintainer who suddenly transfers ownership or a new account that immediately publishes a major version deserves scrutiny.
- Network calls. Grep for
fetch,http,eval, and base64-decoded strings. A date formatter has no business phoning home.
The typosquatting trap
Attackers publish packages named one keystroke off popular ones, like crossenv versus cross-env. Before installing, confirm you have the exact name and that the download counts and repo link match the project you intend to use. This applies just as strongly when vetting plugins for a CMS, which we broke down in our guide to auditing WordPress plugins for data-harvesting vulnerabilities.
When to Stop Vetting and Just Buy Accountability
Here is the honest tradeoff nobody wants to say out loud: some code should not be free-as-in-anonymous. When a component sits in the critical path of authentication, payments, or user data, you don't just want working code. You want someone accountable when it breaks
Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.
