Dipendenze e supply chain nei progetti IA: guida a npm audit

Come verificare le librerie che un progetto IA può aver installato, con npm audit e pip-audit. Guida pratica a package.json, lockfile e aggiornamenti sicuri.

Se hai creato un’app o un sito con Cursor, ChatGPT o strumenti simili, è molto probabile che il progetto dipenda da decine (a volte centinaia) di librerie di terze parti — installate da te o suggerite dall’IA. Questo ecosistema invisibile si chiama software supply chain: la catena di pacchetti da cui dipende il tuo progetto.

Dopo aver controllato codice e configurazione del server nell’audit di sicurezza gratuito (lettura opzionale), il pezzo che spesso manca sono proprio queste dipendenze. In questa guida ti mostro come ispezionare i pacchetti con npm audit (JavaScript/Node.js) e, se usi Python, con pip-audit in un venv — senza inseguire a ogni costo lo “zero vulnerabilità” e senza rompere il sito.

ℹ️ Nota / Prerequisito operativo
Ti serve un progetto locale con un file package.json (Node) oppure un progetto Python con ambiente virtuale. Devi saper aprire un terminale nella cartella del progetto. Gli esempi partono da Windows; i comandi npm sono gli stessi su macOS e Linux, i path e python / python3 no.

Passaggio 1 — Capire se sei in un progetto Node

Quando l’IA genera un sito moderno (React, Next.js, Astro, Vite…), crea di solito un file package.json: è la “lista della spesa” delle librerie. Quelle librerie finiscono in una cartella pesante chiamata node_modules.

Per gestirle serve Node.js, che include il gestore di pacchetti npm.

Windows (percorso principale)

1. Apri PowerShell, Prompt dei comandi o Windows Terminal.
2. Spostati nella cartella del progetto (adatta il path al tuo utente):

cd C:\Users\TuoNome\Progetti\sito-ia

3. Verifica Node e npm:

node -v

npm -v

Output atteso: numeri di versione, ad esempio v20.x.x e 10.x.x.

macOS

cd ~/Progetti/sito-ia

node -v

npm -v

Linux

cd ~/Progetti/sito-ia

node -v

npm -v

Se compare un errore tipo comando non riconosciuto / command not found, Node non è installato (o non è nel PATH). Scarica la versione LTS dal sito ufficiale di Node.js, installala e riavvia il terminale, poi ripeti node -v e npm -v.

Nella cartella del progetto deve esserci package.json. Se manca, non sei nella directory giusta (o il progetto non è Node).

Passaggio 2 — Lanciare npm audit e leggere il report

npm audit confronta le versioni installate (quelle fissate dal lockfile / da node_modules) con un database di advisory pubbliche (ecosistema npm / GitHub Advisory). Segnala vulnerabilità note (CVE e simili) nelle dipendenze — non nel tuo codice applicativo.

Assicurati di essere nella cartella con package.json, poi:

Windows / macOS / Linux:

npm audit

Il report può sembrare allarmante: in progetti generati con assistenti IA possono comparire stack datati o transitive dependencies vecchie. npm classifica di solito la gravità così:

• Low / Moderate — spesso teoriche o con condizioni difficili. Su un sito statico o un progetto ancora locale raramente sono un’emergenza immediata.
• High / Critical — meritano attenzione: possono consentire esecuzione di codice, denial of service o altri abusi noti, a seconda del pacchetto e del contesto.

⚠️ Attenzione — L’audit non analizza il tuo codice
npm audit controlla le librerie di terze parti. Non cerca password in chiaro, SQL injection o bug nella logica scritta da te o dall’IA. È un controllo sulla supply chain, non una code review. Per le scorciatoie tipiche del codice generato vedi (opzionale) le 7 falle di sicurezza nel codice IA.

Opzioni utili di npm audit (una per una)

Non ti servono tutte ogni volta. Ecco quelle che incontri di più:

npm audit (default)
Mostra il report in terminale: conteggi per severità e, spesso, suggerimenti di fix.

npm audit

npm audit --json
Stesso controllo, output JSON (utile se vuoi archiviare il report o passarlo a uno script). Per uso umano preferisci il default.

npm audit --json

npm audit --production
Considera soprattutto le dipendenze di produzione (esclude molte devDependencies). Utile se stai valutando cosa finisce davvero in deploy.

npm audit --production

Aiuto nativo:

npm audit --help

Passaggio 3 — Aggiornare con criterio (audit fix e --force)

La tentazione è azzerare il contatore aggiornando tutto. Spesso è un errore: le major release possono introdurre breaking changes e far fallire il sito generato dall’IA.

npm audit fix

Tenta aggiornamenti alle versioni patchate compatibili con i vincoli già dichiarati in package.json / lockfile.

Windows / macOS / Linux:

npm audit fix

Nella mia esperienza, il fix senza --force è in genere il primo passo ragionevole. Dopo averlo lanciato:

1. Rilancia npm audit e guarda cosa resta.
2. Avvia il progetto come fai di solito (npm run dev, npm start, …) e verifica che la home e le pagine critiche rispondano.

npm audit fix --force

Forza aggiornamenti anche quando rompono i vincoli di versione. npm lo propone a volte per chiudere High/Critical “a ogni costo”.

npm audit fix --force

🚨 Avviso critico — Fermati prima di --force
Su un progetto appena “vibe-coded”, --force ha alta probabilità di rompere import, API e build. Preferisci: (1) backup della cartella o commit Git; (2) chiedere all’IA di aggiornare il codice alla versione nuova della libreria; (3) aggiornare un pacchetto critico per volta con npm install nome@versione e ritestare.

Combinazioni tipiche

1. Solo lettura: npm audit
2. Fix conservativo + verifica: npm audit fix → npm audit → avvio locale
3. Produzione: npm audit --production poi valuta i soli High/Critical rilevanti al deploy
4. Mai come primo gesto su un repo sconosciuto: npm audit fix --force

Passaggio 4 — Il lockfile: perché non cancellare package-lock.json

Oltre a package.json trovi quasi sempre package-lock.json (o, in altri toolchain, file equivalenti come pnpm-lock.yaml / yarn.lock).

• package.json — dichiara le dipendenze “principali” con intervalli di versione.
• package-lock.json — fissa l’albero esatto installato, incluse le dipendenze transitive.

Un errore comune quando l’install fallisce è cancellare node_modules e il lockfile, poi rilanciare npm install.

🚨 Avviso critico — Non cancellare il lockfile alla cieca
Senza lockfile, il prossimo npm install può scaricare versioni più nuove ancora “consentite” dal package.json. In un progetto vibe-coded, dove non conosci ogni interazione tra librerie, puoi rompere l’app in silenzio. Il lockfile serve proprio a riprodurre la stessa copia tra sei mesi (o su un altro PC).

Recupero più sicuro se node_modules è corrotto:

1. Elimina solo node_modules.
2. Lascia package-lock.json.
3. Rilancia:

npm install

Passaggio 5 — Se usi Python: controllo in venv con pip-audit

Se il backend è Flask/FastAPI (o uno script con molte librerie), la supply chain è la stessa idea: pacchetti di terzi sul tuo disco. Gli strumenti cambiano.

Letture opzionali sul cluster Python: quando usare pip install, ambienti virtuali (venv).

1) Entra nella cartella e attiva il venv

Windows (cmd):

cd C:\Users\TuoNome\Progetti\api-ia

.venv\Scripts\activate.bat

Windows (PowerShell):

cd C:\Users\TuoNome\Progetti\api-ia

.venv\Scripts\Activate.ps1

macOS / Linux:

cd ~/Progetti/api-ia

source .venv/bin/activate

Devi vedere (.venv) nel prompt.

2) Elenca i pacchetti installati

Windows:

python -m pip list

macOS / Linux:

python3 -m pip list

3) Installa ed esegui pip-audit

A differenza di npm, pip non include un audit di fabbrica. La PyPA indica pip-audit come strumento per confrontare i pacchetti installati con il Python Packaging Advisory Database.

Windows:

python -m pip install pip-audit

pip-audit

macOS / Linux:

python3 -m pip install pip-audit

pip-audit

Output atteso: elenco vuoto / “No known vulnerabilities found”, oppure pacchetti con CVE e versioni consigliate.

Aggiorna un pacchetto per volta, poi ritesta l’app:

Windows:

python -m pip install nome-pacchetto --upgrade

macOS / Linux:

python3 -m pip install nome-pacchetto --upgrade

Errori comuni e come risolverli

npm / node: comando non riconosciuto
Node non installato o PATH non aggiornato (frequente su Windows subito dopo l’installer). Reinstalla LTS da nodejs.org, chiudi e riapri il terminale, riprova node -v.

ENOENT: no such file or directory, open 'package.json'
Sei nella cartella sbagliata. Controlla con dir (Windows) o ls (macOS/Linux) che package.json sia elencato; poi cd nella directory corretta.

npm install fallisce su un nome strano
L’IA a volte allucina un pacchetto. Prima di forzare installazioni, verifica il nome su npmjs.com. Nomi simili a librerie famose sono un classico vettore di typosquatting.

Dopo audit fix il sito non parte
Ripristina dal backup/commit, evita --force, aggiorna un solo pacchetto critico e chiedi all’IA di adattare gli import al changelog della libreria.

Domande Frequenti (FAQ)

Zero vulnerabilità in npm audit significa che il mio sito è sicuro?

No. npm audit verifica solo se le librerie di terze parti hanno falle già note. Non ti dice se la logica del sito, i permessi del database o gli header HTTP sono a posto. Un report pulito riduce un pezzo di rischio, non chiude l’audit.

Devo aggiornare tutte le dipendenze subito?

No. Un salto di major version spesso rompe il codice (breaking change). Priorità: High/Critical su funzionalità che usi davvero; per il resto parti da npm audit fix (senza --force) e ritesta in locale.

Posso cancellare package-lock.json per risolvere errori di installazione?

È sconsigliato. Meglio cancellare solo node_modules e rilanciare npm install tenendo il lockfile. Cancellare il lockfile ricalcola l’intero albero e può portare versioni incompatibili con il codice generato dall’IA.

Uso solo Python: questa guida mi serve?

Sì, per il meccanismo. In Python non usi npm audit: attivi il venv e usi pip-audit (dopo python -m pip install pip-audit / python3 -m pip …). Il rischio supply chain è lo stesso.

L’IA ha creato il progetto ma non so cos’è npm: da dove parto?

Se c’è un package.json, sei nell’ecosistema Node. Installa Node.js LTS, apri il terminale nella cartella del progetto, lancia npm install per scaricare le librerie, poi npm audit come in questa guida.

Il comando npm audit fix è sempre sicuro?

Di solito è il fix più prudente, perché resta nei vincoli dichiarati. Non è una garanzia assoluta su codice IA imprevedibile: fai un backup o un commit prima, poi verifica che il sito parta ancora.

Conclusioni

Controllare la supply chain non è un rituale una tantum: ripetilo quando l’IA aggiunge funzionalità (e quindi nuove librerie). Un report senza CVE note non sostituisce configurazione, autenticazione e revisione del codice; riduce però il rischio di esporre exploit già pubblici e pronti all’uso.

Se il progetto ha backend o gestione dati, affianca questi controlli all’audit di sicurezza gratuito per siti e app IA e, per le scorciatoie tipiche nel sorgente, alle 7 falle comuni nel codice generato dall’IA.