La Catena di Fornitura del Software si Rompe: npm, Zero-Day e il Mondo in cui Non Puoi Fidarti Nemmeno dei Pacchetti che Usi Ogni Giorno
C’è una domanda che ogni sviluppatore dovrebbe porsi ogni giorno: “Chi ha scritto il codice che sto eseguendo?” La risposta, nella stragrande maggioranza dei casi, è “non lo so con certezza”. Un progetto Node.js di media complessità ha centinaia di dipendenze dirette e migliaia di dipendenze transitive. Ogni singolo pacchetto in quella catena è un potenziale punto di compromissione. E nel 2026, gli attaccanti hanno dimostrato di saperlo e di sfruttarlo sistematicamente.
La catena di attacchi alla supply chain software del 2026 inizia con quello che i ricercatori di sicurezza hanno chiamato “worm Shai-Hulud”. Identificato a marzo 2026, si tratta di un sofisticato attacco al registro npm (Node Package Manager) che ha compromesso oltre 170 pacchetti, con un meccanismo auto-replicante che sfruttava le credenziali di maintainer per propagarsi lateralmente verso altri pacchetti nello stesso ecosistema. Il nome — preso dal verme gigante di Dune — richiama la capacità del malware di muoversi sotto la superficie, invisibile, prima di emergere.
La compromissione TanStack: quando la vittima è OpenAI
L’episodio più eclatante della serie è avvenuto l’11 maggio 2026, quando i ricercatori di sicurezza hanno identificato 84 versioni malevole distribuite su 42 pacchetti del progetto TanStack, uno dei framework JavaScript più utilizzati per la gestione dello stato nelle applicazioni React. TanStack Query (ex React Query) è scaricato milioni di volte al mese. Tra le organizzazioni colpite dalla compromissione figurano, secondo i report, due dispositivi appartenenti all’infrastruttura di sviluppo di OpenAI — il che ha trasformato l’episodio da incidente tecnico a notizia di prima pagina nel settore.
La compromissione di TanStack era una variante di Shai-Hulud, denominata “Mini Shai-Hulud” dai ricercatori. Il meccanismo era elegante nella sua semplicità: i pacchetti malevoli erano identici agli originali ad eccezione di una dipendenza aggiuntiva nascosta in profondità nell’albero, che eseguiva codice arbitrario durante l’installazione tramite lifecycle script (postinstall). Uno script postinstall malevolo in un pacchetto npm viene eseguito con i privilegi dell’utente che fa `npm install`, che in molti pipeline CI/CD è un utente con accesso alle variabili d’ambiente — dove vivono le credenziali di produzione, i token API, le chiavi SSH.
PILLOLA TECNICA — Come difendersi dagli attacchi supply chain npm: (1) Pinning delle versioni: specificare versioni esatte (non range) nel package.json e committare il package-lock.json. (2) npm audit in CI/CD: bloccare le build se emerge una vulnerabilità critica non approvata. (3) Lockfile integrity: verificare l’integrità del lockfile prima di ogni installazione con –frozen-lockfile (npm ci). (4) Disabilitare gli script di lifecycle: npm install –ignore-scripts riduce la superficie ma rompe alcuni pacchetti legittimi. (5) Software Composition Analysis (SCA): strumenti come Snyk, Dependabot, o Socket.dev analizzano il comportamento dei pacchetti oltre alla loro lista CVE, identificando anomalie nei pattern di installazione. (6) SBOM: generare e mantenere una Software Bill of Materials (SBOM) in formato SPDX o CycloneDX permette di sapere esattamente cosa gira in produzione e rispondere rapidamente quando emerge un pacchetto compromesso.
La compromissione Red Hat: quando il canale ufficiale diventa il vettore
Il 1° giugno 2026, l’ACN italiana ha emesso un allerta urgente riguardante la compromissione del namespace @redhat-cloud-services su npm: 32 pacchetti del progetto open source di Red Hat contenevano un payload denominato “Miasma”, progettato per estrarre credenziali cloud (AWS, Azure, GCP) dalle variabili d’ambiente dei sistemi di build. L’allerta ACN era particolarmente significativa perché i pacchetti compromessi erano distribuiti attraverso canali ufficiali verificati, con firme digitali valide. La firma crittografica garantisce che il pacchetto non sia stato manomesso in transito — ma non dice nulla sull’integrità del momento in cui il pacchetto è stato firmato.
Il pattern comune a tutti questi attacchi è la compromissione dell’account del maintainer come punto di ingresso. Se un maintainer riusa password, non ha MFA abilitato sull’account npm, o cade vittima di phishing, l’attaccante ottiene la capacità di pubblicare versioni malevole di pacchetti legittimi con la firma dell’autore originale. Il registro npm non verifica in modo proattivo il comportamento del codice: pubblica ciò che il maintainer autorizzato invia. La fiducia nel canale si trasferisce al contenuto, e questo modello ha un punto di fallimento evidente.
Zero-day su VPN e firewall: quando il perimetro si dissolve
Parallelamente agli attacchi supply chain, il 2026 ha visto una concentrazione preoccupante di zero-day su dispositivi perimetrali. Il dato Google Threat Intelligence per il 2025 è rivelatore: il 48% dei 90 zero-day sfruttati nel corso dell’anno ha colpito infrastruttura enterprise — VPN, firewall, piattaforme di identità, virtualizzazione. Non sistemi consumer, non software per utenti finali: il software che protegge le reti aziendali.
Il CVE-2026-50751 di Check Point (CVSS 9.3) merita attenzione specifica. Si tratta di un bypass di autenticazione sulla funzionalità Remote Access VPN, Mobile Access e Spark Firewall per configurazioni che usano IKEv1. La vulnerabilità è stata sfruttata in-the-wild dal 7 maggio 2026, con un’impennata di attività a inizio giugno. Almeno un incidente documentato è stato attribuito a un affiliato del gruppo ransomware Qilin. La CISA americana l’ha inserita nel Known Exploited Vulnerabilities catalog l’8 giugno, fissando la scadenza per la patch per le agenzie federali a 72 ore. Il CVE-2026-20131 di Cisco, CVSS 10.0 — il massimo possibile —, ha colpito il Firewall Management Center ed è stato sfruttato come zero-day dal ransomware Interlock dal 26 gennaio 2026.
PILLOLA TECNICA — Perché i dispositivi di sicurezza perimetrale sono bersagli primari: (1) accesso privilegiato: una VPN concentrator o un firewall ha visibilità su tutto il traffico di rete e credenziali di accesso a tutti i sistemi interni; (2) esposizione inevitabile: per definizione, questi dispositivi devono essere raggiungibili dall’esterno per svolgere la loro funzione; (3) cicli di aggiornamento lenti: molte organizzazioni aggiornano i dispositivi di rete con cadenza molto più bassa rispetto ai server applicativi, temendo interruzioni del servizio; (4) interfacce di management spesso obsolete: le console web dei firewall sono applicazioni PHP o Java di dieci anni fa, con la corrispondente superficie di vulnerabilità. La raccomandazione operativa per CVE-2026-50751: migrare immediatamente da IKEv1 a IKEv2, applicare la patch disponibile, e condurre una revisione dei log di accesso VPN degli ultimi 30 giorni per identificare accessi anomali precedenti alla discovery pubblica.
La risposta sistemica: verso il SBOM come standard
La risposta a lungo termine agli attacchi supply chain software non è tecnica nel senso ristretto del termine: è sistemica. Il Cyber Resilience Act europeo (in vigore dal 10 dicembre 2024, con obblighi principali dall’11 dicembre 2027) introduce per i produttori di software e hardware con elementi digitali l’obbligo di documentare la composizione del proprio prodotto attraverso una Software Bill of Materials (SBOM). L’SBOM è l’equivalente digitale dell’etichetta degli ingredienti su un prodotto alimentare: una lista completa e leggibile da macchina di tutti i componenti software inclusi nel prodotto, con le relative versioni e licenze.
Obbligatoria nel settore della difesa USA dal 2021 (per tutti i contratti federali), l’SBOM diventa progressivamente uno standard de facto nel 2026. Chi non la produce non può dimostrare di sapere cosa gira nei propri sistemi, e non può rispondere in modo credibile alla domanda “siete stati colpiti dalla compromissione TanStack?” in meno di qualche ora. L’SBOM non risolve il problema della supply chain software, ma rende possibile una risposta rapida quando il problema si manifesta. E nel 2026, il problema si manifesta regolarmente.
