Risposta rapida: Gli attacchi alla catena di fornitura Npm funzionano compromettendo un account di manutenzione affidabile o un CI/CD token, pubblicando una versione dannosa di un pacchetto di cui gli sviluppatori si fidano già e lasciando che gli script di installazione o la logica del worm di quel pacchetto facciano il resto. Tra agosto 2025 e metà 2026, questo schema ha prodotto la più grande ondata di attacchi alla catena di fornitura dei pacchetti npm nella storia del registro, incluso il dirottamento chalk/debug, il Verme Shai-Hulude malware di stato-nazione nascosto in un pacchetto scaricato 100 milioni di volte a settimana. La soluzione non è scansionare il codice dopo che è atterrato. È intercettare i pacchetti dannosi prima che vengano installati e monitorare pipeline per il comportamento esatto che questi attacchi hanno in comune.
Ogni installazione è un atto di fiducia, e gli aggressori lo sanno.
Uno sviluppatore esegue installazione di npmDietro a quel singolo comando si cela un albero di dipendenze con centinaia, a volte migliaia, di pacchetti, la maggior parte dei quali scritti e gestiti da persone che lo sviluppatore non incontrerà mai. Nessuno esamina quell'albero riga per riga. Nessuno ha tempo di farlo.
Quella fiducia è l'obiettivo. Per un attaccante è più economico tentare un attacco di phishing contro un manutentore npm con 2.6 miliardi di download settimanali piuttosto che trovare una vulnerabilità zero-day nel firewall di una Fortune 500. Gli attacchi alla catena di fornitura di npm sfruttano proprio questa asimmetria, e l'ondata 2025-2026 mostra quanto si sia esteso questo sfruttamento: da typosquatting isolato in vermi auto-propaganti che pubblicano i propri pacchetti dannosi più velocemente di quanto qualsiasi essere umano possa reagire.
Cosa si intende per attacco alla catena di fornitura di npm?
Un attacco alla catena di fornitura di npm è qualsiasi incidente in cui un aggressore inserisce codice dannoso nella distribuzione npm pipeline piuttosto che nel codice sorgente di un obiettivo, in modo che il malware arrivi mascherato da un normale aggiornamento delle dipendenze. Il punto di ingresso è solitamente uno di questi tre: le credenziali rubate di un manutentore, una pubblicazione rubata o CI/CD token o una build compromessa pipeline che viene ingannato e pubblicato per conto dell'attaccante. Poiché i pacchetti npm includono automaticamente le dipendenze transitive, un singolo pacchetto compromesso può raggiungere applicazioni che non lo hanno mai dichiarato come dipendenza diretta.
Cronologia: i maggiori attacchi alla catena di fornitura di npm del periodo 2025-2026
Lo schema alla base di ogni attacco alla catena di fornitura dei pacchetti npm
Eliminando i dettagli specifici, quasi tutti gli episodi sopra descritti seguono gli stessi quattro passaggi:
- Compromettete un'identità, non un sistema. Un manutentore vittima di phishing, un token npm trapelato, un PAT di GitHub rubato o un token OIDC estratto da CI/CD memoria del runner. L'attaccante non viola il registro. Prende in prestito la chiave di accesso di qualcun altro.
- Pubblica con un nome di cui gli sviluppatori si fidano già. Non è necessario alcun typosquatting quando il nome reale del pacchetto funziona. Questo è ciò che rende questi attacchi così efficaci contro gli aggiornamenti automatici pipelines: l'aggiornamento sembra assolutamente legittimo.
- Eseguilo prima che qualcuno lo esamini. Script di installazione dannosi, payload offuscati o codice dormiente che si attiva solo in determinate condizioni vengono eseguiti nel momento in cui installazione di npm Viene eseguito, spesso sul laptop di uno sviluppatore, molto prima che una scansione di sicurezza programmata possa rilevarlo.
- Perseverare e, sempre più, diffondersi. Shai-Hulud e i suoi successori utilizzano le credenziali rubate per pubblicare automaticamente il pacchetto infetto successivo, trasformando una singola violazione in una reazione a catena lungo l'intero grafo delle dipendenze.
Perché le solite difese falliscono
La maggior parte degli strumenti AppSec è stata creata per analizzare ciò che è già presente nel repository: CVE noti, modelli di codice statico, problemi di licenza. Questo è necessario, ma strutturalmente arriva troppo tardi per questa classe di attacchi. Quando uno scanner rileva una dipendenza, lo script di installazione potrebbe essere già stato eseguito sulla macchina di uno sviluppatore. Gli antivirus e gli EDR tradizionali monitorano il sistema operativo, non i registri dei pacchetti, quindi non hanno il concetto di una "nuova release npm" come unità di rischio. E come dimostrano gli incidenti TanStack e Red Hat, anche le attestazioni di integrità della build come SLSA provenance Non serve a nulla quando l'attaccante ha legittimamente acquisito l'identità di chi firma i file: la firma è valida, ma il pacchetto rimane comunque dannoso.
La falla che questi attacchi alla catena di fornitura di npm sfruttano si trova specificamente al momento della pubblicazione e dell'installazione, prima che esista una firma per il malware e prima che il pacchetto venga eseguito in qualsiasi ambiente in cui uno scanner tradizionale potrebbe effettuare una scansione.
Come fermare il prossimo attacco alla catena di fornitura di npm
In parte si tratta di disciplina procedurale che ogni team di ingegneri può adottare fin da subito:
- Dipendenze dei pin e commit file di bloccoPertanto, un aggiornamento automatico non può installare silenziosamente una versione dannosa appena pubblicata.
- Disabilitare o isolare gli script di postinstallazione Di default, la maggior parte dei pacchetti non necessita di eseguire codice arbitrario al momento dell'installazione.
- Imponi l'autenticazione a più fattori (MFA) supportata da hardware per gli account di pubblicazione npm., chiudendo l'esatto percorso di phishing che ha compromesso Chalk, il debug e l'account di Qix.
- Mirino e rotazione CI/CD token in modo aggressivoe trattare i token OIDC nella memoria del runner come una credenziale da proteggere, non come un dettaglio di implementazione.
- Osserva lo schema di sblocco-iniezione-riblocco. in CI/CD: una regola di protezione del ramo disabilitata, un commit spinto, la regola riattivata, tutto in una finestra temporale ristretta. È una firma ricorrente di pipelinecompromissione della catena di approvvigionamento a livello
Dove la disciplina di processo viene meno
La disciplina dei processi riduce l'esposizione. Non intercetta un pacchetto dannoso nel momento stesso in cui viene pubblicato, né un worm che si sta già propagando nella rete più velocemente di quanto un essere umano possa gestirlo. È proprio per questo livello che è stata progettata la soluzione di sicurezza della catena di fornitura di Xygeni.
Quello di Xygeni MEW (Malware Early Warning) analizza continuamente i nuovi pacchetti pubblicati su npm, PyPI e Maven, individuando il malware prima che esista una firma anziché dopo, e fornendo le minacce confermate indietro a Quello di Xygeni proprio motore di rilevamento. Il Firewall di dipendenza Analizza in tempo reale npm, PyPI, Maven, NuGet e RubyGems e blocca le installazioni dannose prima che raggiungano il computer di uno sviluppatore o una build. CI/CD rilevamento anomalie orologi pipelineper l'esatto schema comportamentale alla base di incidenti come la compromissione di TanStack, inclusa la sequenza di sblocco-iniezione-riblocco, con una traccia di audit completa. E poiché Xygeni Valutazione e risoluzione dei problemi tramite intelligenza artificiale Applicabile anche ai risultati degli scanner di terze parti, i team non devono eliminare gli strumenti esistenti per colmare questa lacuna.
FAQ: attacchi alla catena di fornitura di npm
Che cos'è un attacco alla catena di fornitura di npm?
Si tratta di un attacco in cui il codice dannoso raggiunge un'applicazione di destinazione attraverso una dipendenza npm fidata piuttosto che attraverso il codice della destinazione stessa, di solito perché un attaccante ha compromesso l'account di un manutentore, un token di pubblicazione o un CI/CD pipelinel'identità di.
Qual è stato il più grande attacco alla catena di fornitura di npm?
Per portata d'impatto, il dirottamento di chalk/debug del settembre 2025 è tra i più estesi: 18 pacchetti con un totale di 2.6 miliardi di download settimanali sono stati compromessi tramite un singolo account di manutentore ottenuto tramite phishing. In termini di novità tecnica, Shai-Hulud ha rappresentato la svolta più significativa, essendo il primo worm auto-propagante nella storia di npm.
Come inizia solitamente un attacco alla catena di fornitura dei pacchetti npm?
Quasi sempre con un'identità rubata: un manutentore vittima di phishing, un token di pubblicazione trapelato o un token rubato CI/CD Credenziali come un token OIDC recuperato dalla memoria di un runner, piuttosto che un'intrusione tecnica in npm stesso.
Un antivirus o un sistema EDR possono bloccare un attacco alla catena di fornitura di npm?
Non in modo affidabile. L'EDR monitora il sistema operativo e non comprende i registri dei pacchetti, e l'antivirus si basa sulle firme, il che lo rende inefficace contro i malware pubblicati prima che esistesse una firma digitale. Per bloccare questa classe di attacchi è necessario monitorare il sistema sia al momento della pubblicazione che dell'installazione, non solo a livello del dispositivo finale.
Le normative SLSA provenance o creare un'attestazione per impedirlo?
Dimostra che pipeline Il pacchetto stesso non è stato manomesso durante la compilazione. Ciò non dimostra che l'identità che ha attivato la compilazione non sia stata compromessa, come hanno dimostrato gli incidenti di TanStack e Red Hat, in cui attestazioni valide erano allegate a pacchetti dannosi.
Come può un team rilevare un pacchetto npm dannoso prima che venga installato?
Eseguendo un'analisi continua del malware, prima della firma, sui pacchetti appena pubblicati, che è proprio lo scopo di un sistema di allerta precoce per il malware e di un firewall per le dipendenze, anziché affidarsi esclusivamente alla scansione a posteriori delle vulnerabilità del codice già presente in un repository.
Dove iniziare
Gli attacchi alla catena di fornitura di Npm non stanno rallentando e la linea di tendenza da Shai-Hulud indica una maggiore automazione, non una minore. I team meglio posizionati per la prossima campagna sono quelli che hanno smesso di trattare ogni installazione di npm come un evento di routine e hanno iniziato a monitorare il registro, il pipelinee l'endpoint come un'unica superficie di attacco connessa.
Il piano Developer di Xygeni include la copertura MEW e Dependency Firewall. per un massimo di 25 repository senza costi aggiuntivi. È un buon punto di partenza per visualizzare cosa è già presente in una struttura di dipendenze.
