How to Prompt AI to Audit Your Dependencies

The prompt that fails is "review my dependencies for security issues" pasted above a package.json. The model does not know today's advisories, it does not know which versions you resolved to, and it will confidently produce a list of plausible-sounding CVEs, some of which do not exist. You will spend an hour checking them.

The prompt that works gives the model output it could not have guessed, then asks it to do the part a scanner cannot: judge which findings matter for your project and which packages have stopped earning their place.

Split the Job First

Two different questions get bundled into "audit my dependencies", and they need different tools.

Run the scanner first, always. Then bring the model the output plus the context the scanner lacks. A model that has to guess your versions is a model that will hallucinate; a model reading your actual audit output is reasoning over facts.

Prompt 1: Triage Real Scanner Output

Run your scanner, paste the whole output, and ask for triage rather than a rewrite of what you pasted. npm audit emits JSON built for exactly this, and the equivalents in other ecosystems do the same.

Below is the full output of `npm audit --json` for a project, plus a description of how the project runs.

Project context:
- A server-rendered web app, no untrusted user uploads
- Runs on Node 22 in a container, no browser bundle
- The `sharp` and `pdfkit` paths are only reachable from an authenticated admin route

For each advisory, tell me:
1. Whether the vulnerable code path is plausibly reachable given the context above
2. The realistic worst case if it is
3. Fix now / fix this sprint / accept with a note, and why
4. Whether the suggested fix is a real version bump or a breaking major

Rank by actual risk to this project, not by CVSS score.
Flag anything where you need information I have not given you.

[paste npm audit --json output]

The value is in the ranking. A critical-severity advisory in a code path your app never executes is a lower priority than a moderate one in your request handler, and CVSS cannot know which is which because CVSS does not know your app. That last line matters too: without it the model fills gaps silently instead of asking.

Prompt 2: Find the Packages Nobody Maintains

Abandonment is a slower problem than a CVE and a more common one. The signals are public but tedious to assemble, so gather them mechanically and let the model read the pattern.

For each dependency below I have pasted: current version, latest version,
last publish date, open issue count, and whether the repo has been archived.

Group them into:
- Actively maintained, no action
- Slowing down, worth watching
- Effectively abandoned, plan a replacement
- Already archived, replace now

For anything in the bottom two groups, name the most common
drop-in alternative and say how big the migration realistically is.

Be explicit when a low publish rate is fine because the package is simply finished.

[paste the table]

That last instruction earns its place. A tiny utility with no commits in three years is often complete rather than dead, and a model told to flag staleness will otherwise flag it. Asking for the distinction gets you a far more useful list.

Prompt 3: Find What You Are Not Using

Unused dependencies are pure cost: install time, bundle size, audit noise, and update surface. Tools like depcheck find candidates but produce false positives on anything imported dynamically or used only in config.

Here is depcheck output listing possibly-unused dependencies,
followed by the results of `grep -rn "<package>" src/ config/` for each one.

For each package, decide: genuinely unused, used in a way depcheck missed,
or unclear.

For the "used in a way depcheck missed" cases, show me the line that proves it.
For "unclear", tell me exactly what to grep for next.

Do not recommend removing anything you cannot show is unused.

[paste depcheck output and grep results]

The final constraint is what makes this safe to act on. Without it you get a confident removal list that breaks your build on a dynamic import. With it, every recommendation comes with its evidence attached, which you can check in seconds.

Prompt 4: Justify the Heavy Ones

For a browser bundle, size is the dependency question that shows up in your metrics. Feed the model your bundle analyser output rather than asking it to recall package sizes.

Below is bundle analyser output with the ten largest dependencies by
gzipped size, and below that, every import of each one in the codebase.

For each: what are we actually using it for, and is the full package
justified by that usage?

Call out specifically:
- Packages imported for one or two functions that have a small standard equivalent
- Whole-library imports where the package supports per-function imports
- Two packages doing substantially the same job
- Anything pulled in only by a dev-time code path but landing in the client bundle

Give me an estimated saving for each suggestion and flag which ones
are risky refactors rather than mechanical ones.

[paste analyser output and imports]

Two packages doing the same job is the finding worth the exercise on its own. It accumulates invisibly, particularly when several people, or several AI coding sessions, have each reached for their own preferred library. That drift is exactly the pattern behind stopping AI coding agents from adding dependencies in the first place.

The Rules That Make These Work

• Paste real output. Every prompt here works because the model is reading evidence rather than recalling package trivia, which is the difference between analysis and plausible fiction.

• Give it your context. Runtime, exposure, which routes are authenticated. Risk ranking is impossible without it and the model will invent an assumption if you do not supply one.

• Demand evidence with each recommendation. "Show me the line that proves it" converts a list you have to verify into a list you can check.

• Let it say it does not know. Models fill silence with confidence unless you give them an explicit exit.

• Verify version numbers and advisory IDs yourself. These are exactly the facts a model gets subtly wrong, and they are quick to confirm.

None of these are clever prompts. They are ordinary applications of the principle underneath prompt engineering: supply the context the model cannot have, constrain the output shape, and give it a way to say it does not know.

If an audit like this becomes routine, the prompts themselves become artefacts worth managing, which is the argument for keeping your prompts under version control. A prompt that reliably produces a good dependency review is as much a tool as the scanner feeding it.

One thing to watch while acting on the output: a model suggesting replacement code can reproduce material from a library it has seen, which is the concern discussed in AI coding agents and licensed code. Reviewing a swap is not just a correctness check.

Frequently Asked Questions

Can AI replace npm audit or Dependabot?

No. Those do a database lookup against current advisories, which a model cannot do reliably from memory. Run them first, then use a model to triage and prioritise what they find.

Why does AI invent CVEs?

Because it is generating plausible text when asked a question it has no current data for. Advisory identifiers follow an obvious pattern, so a fabricated one looks exactly like a real one. Paste scanner output instead of asking from memory.

How do I find unused dependencies reliably?

Combine a tool like depcheck with grep results for each candidate, then have the model classify each one and show the evidence. Never remove a package on a recommendation that does not come with proof.

How often should I run a dependency audit?

Automated vulnerability scanning on every build. The judgement pass, abandonment, duplication and size, works well quarterly, or whenever install time or bundle size starts drifting.

Is it safe to paste my package.json into an AI tool?

A dependency list is usually not sensitive, but it does describe your stack. Check your tool's data retention terms, and never paste lockfiles containing private registry URLs or tokens.