Trier les dépendances vulnérables avec l’IA sans forcer toutes les mises à jour

Commencer ici : à quoi sert ce guide

L’audit des paquets annonce une faille élevée et propose une mise à jour forcée. Faut-il l’appliquer immédiatement ? Le rapport signale un risque de dépendance, sans prouver que votre code déployé utilise la fonction concernée ni que la mise à jour est compatible. Ce guide transforme ce rapport en questions concrètes et en modification testable.

Vous distinguerez dépendance directe ou indirecte, gravité, accessibilité réelle du code vulnérable et migration majeure. Le résultat est une décision documentée avec petite mise à jour et tests, ou une investigation attribuée. Le rapport fourni est fictif pour apprendre sans inventer un vrai avis de sécurité. Une analyse vide signifie seulement qu’elle n’a remonté aucun constat.

Un exemple concret

La réponse ci-dessous illustre le format attendu ; elle ne prétend pas auditer votre application. Elle permet de reconnaître une réponse utile. Suivez les étapes détaillées puis comparez fichiers, tests ou sorties réels à cet objectif. Si l’assistant répond seulement « terminé », demandez le livrable modifié, les preuves et ce qui reste à vérifier.

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.

L’objectif

L’IA peut organiser le rapport, mais le lockfile et l’avis actuel de l’éditeur déterminent les dépendances concernées. Le kit utilise un paquet fictif et example.invalid : ce ne sont pas des affirmations de vulnérabilité réelle.

1. Préparer le périmètre

Décompressez le kit et utilisez Node.js 22 ou supérieur. Aucun npm install n’est nécessaire. Le lecteur accepte une forme simplifiée de rapport npm version 2 et refuse les rapports inconnus ou erreurs du registre.

2. Exécuter le laboratoire local

Exécutez les cinq tests et lisez le résumé. L’accessibilité à l’exécution reste non vérifiée et le changement majeur proposé doit être examiné. Retirer le contrôle d’erreur doit faire échouer le test du registre : un scan raté ne doit pas sembler propre.

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

3. Demander des preuves à l’IA

Le premier prompt distingue dépendance directe, chemin transitif et exposition réelle. Une dépendance de développement peut compter pendant le build ou la CI ; ne l’ignorez pas automatiquement.

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. Vérifier la correction

Le deuxième prompt prépare une correction compatible avec un véritable avis et des tests. npm audit fix --force peut franchir une version majeure. Ce n’est pas un raccourci pour éviter d’examiner le changement.

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. Appliquer à votre projet

Sur un vrai projet npm, la commande interroge le registre configuré et écrit un rapport sans corriger les paquets. Un code non nul peut signaler des vulnérabilités : distinguez-le d’une erreur réseau ou de schéma. Vérifiez les noms privés avant partage, puis imports, tests, build et versions déployées après une correction convenue.

npm audit --json > audit.json

Références officielles

• 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.