Vet a Dependency

npm audit catches known CVEs in packages you already trust. This is the other problem: deciding whether to trust a package in the first place. The goal is an evidence-backed verdict, not a vibe.

What to gather

Pull the facts before judging. Use npm view <pkg>, the npm and GitHub pages, and the published tarball.

• Downloads vs. stars vs. dependents. A package with thousands of weekly downloads, single-digit stars, and no dependents is a mismatch worth explaining. Real adoption shows up in all three. Check the download shape too: organic growth is a curve; isolated single-day spikes with dead baseline around them are manufactured.
• Install scripts. Read package.json for preinstall, install, postinstall. Anything that runs on install is the highest-risk surface, read exactly what it does.
• curl | sh and friends. Any install step that pipes a remote script into a shell, or npx-runs a second package, or registers a persistent MCP server, is a red flag. The package should do what its README says and nothing the README doesn't.
• What it actually does vs. claims. Read the real entry points. Network calls, child_process, filesystem writes outside its own dir, env/credential reads, and telemetry that the README doesn't disclose are all findings.
• Obfuscation. Minified-only source with no readable repo, eval, base64 blobs, or dynamic require of constructed strings. Legitimate packages ship readable code.
• Maintainer and provenance. Account age, other packages, repo activity, whether the npm package's repo link actually matches a real, public repo. A brand-new author with one oddly-popular package warrants more scrutiny.
• Typosquatting. Is the name one character off a popular package? Is it impersonating a known scope?
• License sanity. Missing, contradictory, or relicensed-from-someone-else (a file marked MIT that's actually CC-BY upstream) is both a legal and a trust signal.

How to judge, and how to phrase it

Separate what the evidence supports from what it doesn't. This is the discipline that keeps a verdict defensible:

• You can say a package behaves in ways that warrant caution and point at the exact behavior (an undisclosed postinstall, a downloads/stars mismatch, an undisclosed network call). That's an evidence claim.
• You generally cannot say it "is malware" or attribute it to a specific actor or coordinated scheme. Intent and authorship usually aren't provable from the artifact. Don't claim what you can't show.
• Stars and dependents are a truer adoption signal than downloads, which are cheap to manufacture. Weight accordingly.

Output

A short report:

• Verdict: Safe to add / Add with caution / Avoid.
• Evidence: the specific findings, each tied to what you observed, in order of severity.
• If "caution" or "avoid": what would have to change to trust it, or a safer, more-adopted alternative.

Never soften a real finding to be agreeable, and never inflate a thin one into an accusation. Report what the artifact shows.