Valutare dipendenze vulnerabili con IA senza forzare tutti gli aggiornamenti
Leggi npm audit, separa gravità e raggiungibilità e verifica un aggiornamento compatibile. Rapporto fittizio e cinque test inclusi.

Inizia qui: a cosa serve la guida
Un audit propone un aggiornamento forzato per una vulnerabilità grave. Non dimostra raggiungibilità del codice né compatibilità. Distinguerai dipendenze dirette/transitive, gravità, raggiungibilità e migrazione maggiore. Il risultato è una decisione con modifica e test o indagine assegnata. Il rapporto è fittizio; scansione vuota non significa sicurezza provata.
Un esempio concreto
La risposta illustra il formato atteso, non un audit della tua applicazione. Segui i passaggi e confronta file, test e risultati reali. Se l’assistente dice soltanto di aver finito, chiedi il risultato concreto, le prove e cosa resta da verificare.
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’obiettivo
L’IA organizza il rapporto, ma lockfile e avviso attuale del fornitore determinano le dipendenze interessate. Il kit usa un pacchetto fittizio ed example.invalid: non è una dichiarazione di vulnerabilità reale.
1. Definire il perimetro
Estrai il kit e usa Node.js 22 o successivo. Non serve npm install. Il lettore accetta una forma semplificata di rapporto npm versione 2 e rifiuta rapporti sconosciuti o errori del registro.
2. Eseguire il laboratorio locale
Esegui i cinque test e leggi il riepilogo. La raggiungibilità a runtime resta non verificata e il cambio di versione principale richiede revisione. Rimuovere il controllo d’errore dovrebbe far fallire il test del registro: una scansione fallita non è pulita.
node --test lab.test.mjs
node lab.mjs audit.synthetic.json3. Chiedere prove all’IA
Il primo prompt distingue dipendenza diretta, percorso transitivo ed esposizione a runtime. Una dipendenza di sviluppo può contare durante build e CI; non ignorarla automaticamente.
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. Verificare la correzione
Il secondo prompt prepara un aggiornamento compatibile con un avviso reale e test. npm audit fix --force può cambiare versioni principali. Non sostituisce l’esame della modifica.
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. Applicare al proprio progetto
In un vero progetto npm, il comando interroga il registro configurato e scrive un rapporto senza correggere pacchetti. Un codice non zero può indicare risultati: distinguilo da errori di rete o schema. Controlla nomi privati prima della condivisione, poi import, test, build e versioni distribuite dopo una modifica concordata.
npm audit --json > audit.jsonRiferimenti ufficiali
Portalo nel tuo progetto
Scarica i file, conserva la guida o consegna al tuo assistente istruzioni pronte.
Prepara con l’IA
Copia questo prompt inglese nel tuo assistente. Include articolo, file disponibili e passaggi di preparazione.
Mostra il prompt di preparazione
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.

