In breve: la sicurezza della catena di fornitura di npm oltre lo scanner di vulnerabilità
La sicurezza della catena di fornitura npm è la pratica di assicurarsi che ogni pacchetto installato dai progetti JavaScript sia legittimo, non modificato e sicuro, non solo esente da vulnerabilità note.
- Il divario: Un classico scanner di vulnerabilità npm confronta i pacchetti con i database CVE. Un pacchetto dannoso non ha un CVE, quindi viene considerato valido.
- La prova: Nel marzo 2026, un account di manutenzione violato ha trasformato Axios, con oltre 100 milioni di download settimanali, in un canale di diffusione di malware per circa tre ore.
- Il punto di ingresso: la maggior parte degli attacchi npm avviene tramite script di installazione, che vengono eseguiti nel momento in cui digiti
npm install. - La correzione: Individuare i comportamenti dannosi al momento della pubblicazione dei pacchetti, non dopo la comparsa di una vulnerabilità CVE, e rafforzare le modalità di esecuzione delle installazioni.
Il 31 marzo 2026, migliaia di sviluppatori hanno eseguito il comando JavaScript più comune: npm installAlcuni di loro avevano scaricato una nuova versione di Axios, il client HTTP presente in un'enorme quantità di applicazioni web in tutto il mondo. I loro scanner di dipendenze risultavano positivi. Le loro build erano andate a buon fine. E un trojan di accesso remoto si è insinuato silenziosamente nei loro computer.
In quella storia non c'era nessuna vulnerabilità. Ed è proprio per questo che così tanti programmi di sicurezza npm non l'hanno rilevata.
Che fine ha fatto Axios?
L'attacco è stato semplice e paziente. Secondo il Analisi post-mortem dei manutentori di Axios, due versioni dannose, 1.14.1 e 0.30.4, sono state pubblicate tramite l'account compromesso del manutentore principale. L'attaccante non ha toccato una singola riga di codice di axios. Hanno aggiunto una nuova dipendenza, plain-crypto-js, che ha gestito un postinstall script che ha recuperato un carico utile di secondo stadio.
Microsoft Threat Intelligence ha attribuito l'infrastruttura a Sapphire Sleet, un attore statale nordcoreano. Le versioni avvelenate sono rimaste attive per circa tre ore prima che npm le rimuovesse. Per qualsiasi CI pipeline o un laptop che si è installato durante quella finestra temporale, tre ore sono state sufficienti.
Non si trattava di un caso isolato. Nel settembre 2025, il worm Shai-Hulud si diffuse su centinaia di pacchetti npm rubando i token dei manutentori e ripubblicandosi. Tecnica diversa, stessa lezione: in npm, la fiducia viene ereditata automaticamente e gli aggressori lo sanno.
Perché il tuo scanner di vulnerabilità npm non ha rilevato nulla
La maggior parte dei team considera la sicurezza della catena di fornitura di npm come un problema di vulnerabilità. Utilizzano uno scanner di vulnerabilità per npm, che confronta la loro struttura delle dipendenze con database di falle note, e risolvono ciò che viene segnalato. Questo lavoro è importante, ma risponde a una domanda diversa.
| Dimensioni | Pacchetto vulnerabile | Pacco dannoso |
|---|---|---|
| Cos'è | Codice legittimo con un bug | Codice scritto per farti del male |
| Presenta un CVE? | Di solito, alla fine | Quasi mai |
| Quando è pericoloso | Quando il difetto è raggiungibile e sfruttato | Nel momento in cui si installa |
| Cosa lo cattura | Una ricerca nel database delle vulnerabilità | Analisi del comportamento del pacchetto stesso |
| Tempo di risposta tipico necessario | Giorni a settimane | Da minuti a ore |
Un database delle vulnerabilità può descrivere solo qualcosa che qualcuno ha già analizzato e catalogato. Un pacchetto dannoso pubblicato un'ora fa non ha alcuna voce da nessuna parte. Quindi lo scanner restituisce un risultato pulito, e un risultato pulito viene interpretato come sicuro.
Questo è il cambiamento fondamentale nella sicurezza della catena di fornitura di npm: la domanda non è più "questo pacchetto presenta una vulnerabilità nota?" ma "questo pacchetto sta facendo qualcosa che non dovrebbe?".
Quattro modi in cui gli aggressori possono accedere ai tuoi node_modules
- Acquisizione dell'account. Rubare le credenziali o il token di un manutentore e pubblicare una versione infetta di un pacchetto di cui gli utenti si fidano già. Questa è la strategia tipica di Axios, ed è la più difficile da individuare perché il nome del pacchetto è esattamente quello corretto.
- Typosquatting. Pubblica
axoisorreqeustse aspettare che un errore di battitura, un copia-incolla da un tutorial scadente o un assistente di programmazione basato sull'intelligenza artificiale suggeriscano il nome sbagliato. - Confusione di dipendenza. Pubblica un pacchetto pubblico con lo stesso nome di uno dei tuoi pacchetti interni. Se la configurazione del tuo registro preferisce quello pubblico, installerai il codice dell'attaccante.
- Installa gli script. Il filo conduttore in quasi tutti i casi precedenti. npm permette l'esecuzione dei pacchetti
preinstallandpostinstallgli script vengono eseguiti automaticamente, quindi il codice dannoso viene eseguito prima che chiunque importi qualcosa. CISLa guida di A sul compromesso di Axios consiglia di impostareignore-scripts=trueper precisely per questo motivo.
Come si presenta in pratica la sicurezza della catena di approvvigionamento di npm.
Non riuscirai a fermare ogni attacco con un solo metodo. Puoi però renderti un bersaglio molto più difficile adottando alcune abitudini:
- Commit il tuo file di blocco e installa con
npm ci. Le build dovrebbero installare esattamente ciò che è stato revisionato, mai ciò che il registro ha fornito quella mattina. - Disabilita gli script di installazione per impostazione predefinita. Impostato
ignore-scripts=truee consentire gli script solo per i pacchetti che ne hanno effettivamente bisogno. - Definisci l'ambito dei tuoi pacchetti interni. I nomi interni senza ambito rappresentano un invito aperto alla confusione delle dipendenze.
- Verificare la provenienza. npm supporta dichiarazioni di provenienza che collegano un pacchetto pubblicato al suo codice sorgente e alla sua build. Un rilascio improvviso senza di essi, da un progetto che normalmente li prevede, è un segnale d'allarme che vale la pena automatizzare.
- Abbina la scansione delle vulnerabilità al rilevamento del malware. Utilizzate lo scanner di vulnerabilità npm solo per i difetti noti e aggiungete un sistema di rilevamento che analizzi il funzionamento effettivo dei nuovi pacchetti.
La quinta abitudine è quella che la maggior parte dei team trascura, ed è proprio quella che l'attacco Axios ha messo in luce.
Intercetta il pacchetto dannoso prima che abbia un nome
Quello di Xygeni Allerta precoce sul malware (MEW) Scansiona i nuovi pacchetti sui registri pubblici, incluso npm, non appena vengono pubblicati e ne analizza il comportamento del codice anziché attendere una firma nota. Quando un pacchetto viene segnalato, gli utenti interessati vengono avvisati tramite e-mail, piattaforme di messaggistica o web.hookse il pacco è messo in quarantena quindi puoi fermarlo a tuo CI/CD guardrails.
Intorno ad esso, Quello di Xygeni open source security cattura il resto di ciò su cui si basano i quattro percorsi di attacco sopra descritti: typosquatting, confusione delle dipendenze, script di installazione sospetti e componenti npm interni non coperti. Copre anche le vulnerabilità note dagli avvisi di NVD, OSV e GitHub, prioritarie in base alla raggiungibilità in modo da correggere ciò che è effettivamente sfruttabile, con automatico pull requests per le correzioni.
MEW è incluso nel piano gratuito per sviluppatori. Inizia gratis e scansiona i tuoi primi progetti npm in pochi minuti.
FAQ
Che cos'è la sicurezza della catena di fornitura di npm?
La sicurezza della catena di fornitura di npm copre ogni rischio introdotto dai pacchetti da cui dipendono i tuoi progetti JavaScript: vulnerabilità note, pacchetti dannosi, account di manutentori compromessi, typosquatting e confusione tra dipendenze. Va oltre la semplice scansione delle vulnerabilità per verificare che ciò che installi sia legittimo.
Uno scanner di vulnerabilità npm è in grado di rilevare malware?
Di solito no. Un tradizionale scanner di vulnerabilità npm confronta i pacchetti con i database delle vulnerabilità note. Un pacchetto dannoso appena pubblicato non ha alcuna voce nel database, quindi viene considerato valido a meno che lo strumento non analizzi anche il comportamento del pacchetto.
Is npm audit abbastanza?
npm audit È un utile strumento gratuito per individuare le vulnerabilità note. Non rileva malware di recente pubblicazione, typosquat o problemi di dipendenza e non indica se una funzione vulnerabile è effettivamente raggiungibile dal codice.
Come faccio a sapere se un pacchetto è dannoso?
Tra i segnali di allarme si annoverano script di installazione che scaricano o eseguono codice remoto, codice offuscato, chiamate di rete non correlate allo scopo del pacchetto, una nuova dipendenza a cui il repository sorgente non fa mai riferimento e una release priva della provenienza che il progetto pubblica normalmente.
