L’ecosistema JavaScript si prepara a uno dei cambiamenti di sicurezza più significativi degli ultimi anni. GitHub ha annunciato che con il rilascio di npm 12, previsto per luglio 2026, verrà disabilitata per impostazione predefinita l’esecuzione automatica degli script di installazione delle dipendenze. La decisione rappresenta una risposta diretta alla crescita degli attacchi alla supply chain software, una minaccia che negli ultimi anni ha colpito sviluppatori, aziende e infrastrutture critiche attraverso pacchetti apparentemente legittimi. L’annuncio arriva in un momento particolarmente delicato, segnato dall’emersione del codice sorgente del worm Miasma, una piattaforma offensiva avanzata progettata per compromettere repository, ambienti di build e registri software come npm, PyPI e RubyGems. Le due vicende sono strettamente collegate: mentre GitHub riduce la possibilità che codice malevolo venga eseguito automaticamente durante l’installazione di una dipendenza, il caso Miasma dimostra quanto sofisticati e autonomi siano diventati gli attacchi moderni contro la filiera open source.
Cosa leggere
GitHub elimina l’esecuzione automatica degli script npm
Con npm 12, gli script preinstall, install e postinstall non verranno più eseguiti automaticamente durante il comando npm install. La modifica interessa anche altri meccanismi spesso utilizzati dai pacchetti per eseguire codice in fase di installazione, inclusi prepare, compilazioni native tramite node-gyp e operazioni collegate a dipendenze provenienti da repository Git, file locali o link simbolici. GitHub considera gli script di lifecycle la più grande superficie di esecuzione di codice dell’intero ecosistema npm. Ogni volta che uno sviluppatore installa una dipendenza, il sistema concede implicitamente la possibilità di eseguire codice arbitrario proveniente da terze parti. In un contesto in cui una singola dipendenza compromessa può propagarsi a migliaia di progetti, questo modello di fiducia è diventato sempre più difficile da sostenere. Con la nuova impostazione, l’esecuzione di tali script diventa una scelta esplicita e non più un comportamento automatico. Gli sviluppatori dovranno approvare i pacchetti che richiedono queste funzionalità, trasformando un meccanismo storicamente invisibile in una decisione consapevole.
La sicurezza diventa un modello opt-in invece che implicito
La filosofia alla base di npm 12 segna un cambiamento culturale importante. Per anni l’ecosistema JavaScript ha operato assumendo che le dipendenze installate fossero affidabili per definizione. Questa fiducia implicita ha però favorito campagne malevole che sfruttavano proprio gli script di installazione per eseguire codice dannoso sulle macchine degli sviluppatori e nei sistemi di integrazione continua. GitHub introduce quindi un modello in cui le operazioni più rischiose richiedono un’esplicita autorizzazione. Gli sviluppatori dovranno aggiornare almeno a npm 11.16.0 per ricevere avvisi sulle dipendenze che utilizzano script di lifecycle e potranno utilizzare il comando npm approve-scripts per approvare selettivamente i pacchetti considerati affidabili. Quando npm 12 entrerà in produzione, tutti gli script non precedentemente autorizzati verranno bloccati automaticamente. L’obiettivo non è eliminare la funzionalità, ma limitare la possibilità che codice malevolo venga eseguito senza che il responsabile del progetto ne sia consapevole.
Le dipendenze Git e gli URL remoti diventano controllati
Oltre agli script di installazione, GitHub introduce restrizioni significative anche per le dipendenze provenienti da repository Git e da URL remoti. In passato npm poteva risolvere automaticamente dipendenze che puntavano a repository GitHub o a file compressi scaricati tramite URL HTTPS. Questo comportamento, pur comodo, apriva ulteriori superfici di attacco perché permetteva a pacchetti compromessi di scaricare codice esterno o modificare configurazioni locali attraverso file .npmrc opportunamente manipolati. Con npm 12, le dipendenze Git non verranno più risolte automaticamente e richiederanno l’utilizzo di autorizzazioni specifiche. Anche il parametro –allow-git sarà impostato su none come configurazione predefinita. Lo stesso approccio verrà applicato ai pacchetti distribuiti tramite URL diretti. In pratica, npm passerà da un modello permissivo a uno restrittivo, dove ogni forma di esecuzione o acquisizione di codice esterno richiede un consenso esplicito.
GitHub rafforza una strategia avviata con min-release-age
Le modifiche introdotte in npm 12 non rappresentano un intervento isolato. All’inizio del 2026 GitHub aveva già introdotto la funzione min-release-age, progettata per impedire l’installazione automatica di pacchetti pubblicati troppo recentemente. Molti attacchi supply chain sfruttano infatti il breve intervallo temporale che intercorre tra la pubblicazione di un pacchetto malevolo e la sua identificazione da parte della community. Impostando un’età minima per i pacchetti accettati, le organizzazioni possono ridurre il rischio di installare codice dannoso appena pubblicato. La combinazione tra min-release-age, approvazione degli script e limitazioni sulle dipendenze Git costruisce un modello di sicurezza multilivello che punta a ridurre drasticamente l’esposizione dell’ecosistema npm agli attacchi automatizzati.
Il worm Miasma emerge pubblicamente su GitHub
L’annuncio di npm 12 coincide con un episodio che ha attirato l’attenzione della comunità di sicurezza: la pubblicazione del codice sorgente del worm Miasma. Per un breve periodo il malware è comparso all’interno di repository GitHub creati utilizzando account compromessi. Gli aggressori hanno utilizzato repository denominati Miasma-Open-Source-Release, suggerendo una diffusione deliberata e non accidentale del codice. Miasma rappresenta una delle minacce più avanzate emerse recentemente nell’ambito della supply chain open source. Il malware è progettato per sottrarre credenziali da ambienti di sviluppo, infrastrutture cloud, cluster Kubernetes, password manager e sistemi CI/CD. Una volta ottenute le credenziali, è in grado di compromettere repository software e pubblicare pacchetti malevoli su piattaforme come npm, PyPI e RubyGems, propagandosi autonomamente attraverso l’ecosistema.
Miasma evolve il modello offensivo di Shai-Hulud
Gli analisti considerano Miasma l’evoluzione diretta del worm Shai-Hulud, responsabile di precedenti compromissioni che avevano coinvolto pacchetti npm utilizzati anche da organizzazioni di primo piano. A differenza di molti malware tradizionali, Miasma non dipende da una classica infrastruttura di comando e controllo. Utilizza direttamente le piattaforme di sviluppo compromesse per diffondersi e mantenere la persistenza. Il codice trapelato mostra una struttura particolarmente sofisticata che include cifratura AES-256-GCM, sistemi di offuscamento avanzati e una pipeline di build capace di generare payload differenti per ogni compilazione. Questa caratteristica rende molto più difficile identificare il malware tramite semplici firme statiche. Ancora più preoccupante è la presenza di un dead-man switch, una funzionalità che attiva comportamenti distruttivi qualora il token GitHub rubato venga revocato. In tale scenario il malware tenta di cancellare file e directory presenti sul sistema compromesso, aumentando l’impatto dell’incidente.
Il leak del codice aumenta il rischio di imitazione
La pubblicazione del codice sorgente modifica profondamente il livello di rischio associato a Miasma. Finché il malware restava nelle mani del gruppo che lo aveva sviluppato, la minaccia era limitata alle capacità operative di un numero ristretto di attori. Con la disponibilità del codice, altri gruppi criminali possono studiarne l’architettura, modificarla e adattarla alle proprie campagne. È uno schema già osservato in passato con numerosi malware open source o trapelati online. La disponibilità del codice riduce i costi di sviluppo e accelera la proliferazione di varianti derivate. Per questo motivo molti ricercatori considerano il leak di Miasma un evento significativo per la sicurezza dell’intero ecosistema open source.
Gli sviluppatori devono prepararsi a npm 12
L’arrivo di npm 12 richiederà una fase di adattamento per numerosi progetti. Molti pacchetti fanno ancora affidamento sugli script di installazione per compilare componenti native, generare asset o configurare dipendenze aggiuntive. Gli sviluppatori dovranno identificare quali pacchetti necessitano realmente di tali funzionalità e predisporre le opportune approvazioni. È consigliabile iniziare immediatamente la migrazione utilizzando le versioni più recenti di npm, così da ricevere avvisi preventivi e verificare eventuali incompatibilità. Le organizzazioni che gestiscono pipeline CI/CD dovrebbero inoltre testare l’impatto delle nuove impostazioni in ambienti isolati prima dell’adozione definitiva di npm 12.
La supply chain open source entra in una nuova fase
Le decisioni di GitHub mostrano chiaramente che la sicurezza della supply chain software sta diventando una priorità strategica per l’intero settore. L’epoca in cui l’installazione di una dipendenza implicava automaticamente l’esecuzione di codice proveniente da Internet senza alcuna verifica sta progressivamente terminando. Il caso Miasma dimostra quanto rapidamente gli attori malevoli stiano evolvendo le proprie tecniche, trasformando repository, registri di pacchetti e pipeline di build in vettori di compromissione su larga scala. Con npm 12, GitHub tenta di ridurre questa superficie di attacco imponendo un modello di fiducia esplicita e controllata. Per sviluppatori e aziende significa più lavoro iniziale nella gestione delle dipendenze, ma anche una maggiore resilienza contro una delle minacce più pericolose dell’attuale panorama open source.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
