Triage vulnerable dependencies with AI without blindly forcing an update

Start here: why this guide is useful

Your package audit reports a high-severity issue and offers a forced upgrade. Should you apply it immediately? A vulnerability report identifies a dependency risk, but it does not by itself establish whether your deployed code reaches the affected feature or whether the proposed update breaks your application. This guide turns the report into a sequence of questions and a testable change.

You will distinguish direct and transitive dependencies, advisory severity, reachability and major-version migration. The final result is a documented decision with a small update and regression evidence, or a clearly owned investigation. The supplied report is fictional: it teaches interpretation without inventing a real security advisory. An empty scan means no findings reported by that scan, not proof that everything is secure.

A concrete example

The following is an illustrative response format, not the result of an audit of your application. Use it to recognise what a useful answer should contain. Follow the detailed steps below, then compare the actual files, tests or output with this target. If the assistant only says “done”, ask for the changed artifact, the evidence and what remains unverified.

Package: example-library (fictional fixture).
Reachability: unverified; inspect the actual import and runtime path.
Proposed major upgrade: review breaking changes before installation.
Evidence required: advisory range, resolved version and regression results.

The goal

AI can organise an audit report, but the lockfile and current vendor advisory decide which dependency is affected. This lab uses a fictional package and example.invalid link; neither is a real vulnerability claim.

1. Prepare the scope

Extract the kit into a new folder and use Node.js 22 or newer. No npm install is needed for the lab. The small reader accepts a simplified npm report-version-2 shape and fails on unsupported reports or registry errors.

2. Run the local lab

Run the five tests and read the summary. The example marks runtime reachability as unverified and flags a proposed major change for review. Removing the error check should make the registry-failure test fail: an unsuccessful scan must not look clean.

node --test lab.test.mjs
node lab.mjs audit.synthetic.json

3. Ask AI for evidence

Use the first English prompt to distinguish direct dependencies, transitive paths and runtime exposure. A dev-only dependency can still matter during builds or CI; do not automatically ignore it.

Act as a dependency-security reviewer. Start with this kit’s audit.synthetic.json
and lab.mjs. This fixture and its example.invalid URL are fictional, not a real
package advisory. Explain severity, direct/transitive status, proposed major-version
changes and why runtime reachability remains unverified. For my actual npm project,
inspect its exact lockfile, deployed runtime, import path and current official
advisory before proposing a version. Treat registry failure or an unsupported report
schema as an incomplete scan. Never invent a CVE, fixed version or package name. Do
not install packages or run npm audit fix --force.

4. Verify the correction

The second prompt prepares one compatible update, with a real advisory and regression checks. npm audit fix --force can cross major versions. Do not use it as a shortcut around understanding the change.

For one confirmed real dependency finding, show the affected installed version,
trustworthy advisory URL, dependency path, runtime/build usage, compatible fix and
required regression tests. Propose the smallest reviewed update using the project’s
existing package manager and lockfile. Check install scripts and major-version
changes before execution. After an agreed local change, run the actual build/tests
and a fresh audit; distinguish remaining known findings from operational scan
errors. Do not suppress an unresolved finding just to make CI green, and stop before
production deployment.

5. Apply it to your project

For an actual npm project, the command below queries its configured registry and writes a report without fixing packages. It can exit nonzero when findings exist; distinguish that from a registry or schema error. Review private package names before sharing a report, then verify imports, tests, build and deployed versions after an agreed update.

npm audit --json > audit.json

Official references

• npm · Official audit command
• OWASP · AI-assisted development and dependency review

Read this tutorial as reference material:
https://nethanelfitoussi.com/article/ai-dependency-audit-workflow?lang=en

Goal: apply the documented workflow to my development project.
Read the existing project instructions, inspect the relevant files and explain the smallest useful setup.

Available starter files:
https://nethanelfitoussi.com/api/media/bb103752-1438-4b7d-a74c-9a429f633ae7.zip
Download and inspect these files in a temporary folder before using them. Do not overwrite existing project instructions.

If I have not supplied a project folder, ask which development project to use. Do not invent a repository URL.

Additional project setup instructions:
Use the downloaded starter lab in a NEW folder. Read README.md and both English prompts first. Run its dependency-free Node.js tests before editing.

Act as a dependency-security reviewer. Start with this kit’s audit.synthetic.json
and lab.mjs. This fixture and its example.invalid URL are fictional, not a real
package advisory. Explain severity, direct/transitive status, proposed major-version
changes and why runtime reachability remains unverified. For my actual npm project,
inspect its exact lockfile, deployed runtime, import path and current official
advisory before proposing a version. Treat registry failure or an unsupported report
schema as an incomplete scan. Never invent a CVE, fixed version or package name. Do
not install packages or run npm audit fix --force.

For one confirmed real dependency finding, show the affected installed version,
trustworthy advisory URL, dependency path, runtime/build usage, compatible fix and
required regression tests. Propose the smallest reviewed update using the project’s
existing package manager and lockfile. Check install scripts and major-version
changes before execution. After an agreed local change, run the actual build/tests
and a fresh audit; distinguish remaining known findings from operational scan
errors. Do not suppress an unresolved finding just to make CI green, and stop before
production deployment.

Adapt example paths, commands and acceptance criteria to this repository rather than assuming they match.

Give me a short plan, then make the agreed local changes and run the relevant checks. Report actual results and anything not verified. Stop before credentials, paid services, production changes, push, merge or deployment.