DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

How to vet an npm package before installing it in an AI-built app

#ai #security #npm #webdev

Quick answer

When an AI coding assistant suggests an npm package, do not approve the install just because the generated code looks plausible. Treat package installation as a privileged operation.

Before you run npm install, check five things:

  1. The package name exists in the right ecosystem.
  2. The maintainer, repository, release history, and purpose match what you expected.
  3. The package does not hide surprising install scripts, binaries, or unrelated dependencies.
  4. Provenance, registry signatures, vulnerability data, and malware alerts do not show obvious red flags.
  5. The feature is worth the added dependency surface.

For an indie app, the practical default is simple: no AI-suggested dependency gets installed automatically. The agent may propose a package, but a human or a script must vet it first.

Who this is for

This guide is for solo founders and small teams building with Codex, Claude Code, Cursor, Copilot, or other AI coding agents. It is especially useful when the agent says something like:

I can solve this by installing a small package:
npm install
Enter fullscreen mode Exit fullscreen mode

That suggestion may be fine. It may also be stale, unnecessary, hallucinated, typosquatted, slopsquatted, abandoned, or malicious. The point is not to fear npm. The point is to slow down when a text suggestion turns into executable third-party code.

What changed and why now

AI coding tools changed the dependency decision. A developer used to search for a package, read the README, check the repository, and then install it. In an agent workflow, the model may pick the dependency, write the import, edit the code, run the install command, and keep going.

That compression creates a weak point. Research on package hallucinations shows that coding models can recommend package names that do not exist. Once a fake name becomes predictable, an attacker can register it and wait for developers or agents to install it. This is often called slopsquatting.

The npm ecosystem is also adding clearer supply-chain checks. npm documents package provenance and npm audit signatures. GitHub added Dependabot malware alerts for npm dependencies in 2026. OSV-Scanner and OpenSSF Scorecard add practical checks for known vulnerabilities and repository health. None replaces judgment, but together they turn "the AI said to install it" into a reviewable decision.

The 15-minute package intake workflow

1. Ask why the package is needed

Start by making the agent justify the dependency:

Before installing, explain the problem, alternatives, package identity,
install scripts or binaries, files changed, and next command.
Do not install yet.
Enter fullscreen mode Exit fullscreen mode

If the answer is vague, reject the install. Small apps become harder to ship when every minor feature adds another third-party package.

2. Verify the package identity

Use npm metadata before installation:

npm view  name version description repository homepage bugs license
npm view  maintainers time dist-tags
npm view  scripts dependencies optionalDependencies peerDependencies bin
Enter fullscreen mode Exit fullscreen mode

Look for missing or unrelated repositories, mismatched maintainers, very new packages claiming maturity, names that look like convenient variants of real packages, and scripts, bin, or dependencies that are too large for the job. Download counts are not a trust signal; the package identity has to make sense.

3. Inspect the tarball without running it

Before installing, inspect what npm would fetch:

npm pack @latest --dry-run
npm pack @latest
tar -tf -*.tgz | sed -n '1,80p'
Enter fullscreen mode Exit fullscreen mode

For a tiny utility, the package should not contain unexpected binaries, credential-looking files, huge vendored folders, or postinstall-heavy scaffolding. If it has install scripts, assume they can execute locally.

When you need a safer first install, use:

npm install  --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

That does not make a malicious package safe, but it prevents lifecycle scripts from running during the first look.

4. Check signatures, provenance, and known badness

After installing into a disposable branch or sandbox, run:

npm audit signatures
osv-scanner scan -r .
Enter fullscreen mode Exit fullscreen mode

npm audit signatures checks registry signatures and available provenance attestations. OSV-Scanner checks dependency data against OSV vulnerability records. For public GitHub repositories, OpenSSF Scorecard adds a maintainer-health signal across security policy, dependency updates, CI, branch protection, and build practices.

If the package enters your GitHub repository, enable Dependabot alerts and npm malware alerts. That gives you follow-up visibility when an advisory appears later.

5. Decide with a dependency budget

Use a simple rule:

Install if:
- it solves a real problem;
- identity, repository, tarball, scripts, and scans are acceptable;
- the feature is worth the maintenance cost.

Reject or replace if:
- the package only saves a few lines of code;
- the AI cannot explain why this exact package is needed;
- a smaller existing dependency or native API can do the job.
Enter fullscreen mode Exit fullscreen mode

For a solo product, "I can write 20 lines myself" is often safer than adding another dependency that runs code during install.

Decision tree 

AI suggested the name?
  -> verify name, maintainer, repo, scripts, and tarball.
Install scripts or binaries?
  -> use a sandbox or --ignore-scripts first.
Signature, provenance, or OSV scan fails?
  -> stop and investigate.
Not needed for a core feature?
  -> prefer native code, an existing dependency, or a smaller implementation.
Enter fullscreen mode Exit fullscreen mode

Common mistakes

  • Letting agents install dependencies in auto-approve mode. Installing registry code is not the same as editing a local file.
  • Checking only the README. A compromised package can have a clean README and a dangerous tarball, script, or dependency chain.
  • Treating provenance as a magic safety badge. Provenance can connect a package to a build workflow, but it does not prove the code is harmless.
  • Merging without a lockfile diff review. The real change is often the full dependency graph, not one line in package.json.

FAQ

Should I ban AI agents from installing packages?

No. Agents can propose installs, but they should not silently approve them. For production apps, require a review note and lockfile check.

Is npm audit enough?

No. npm audit and OSV-style scans find known issues. They do not prove a package name is real, necessary, well maintained, or free from risky install behavior.

What should I put in AGENTS.md?

Add: "Do not install new npm packages without explaining the reason, package identity, script risk, and alternatives. Prefer existing dependencies or native APIs for small tasks." If your repo already uses shared agent rules, pair this with the broader AGENTS.md setup guide.

Sources

Top comments (0)