C’è una frase nel report Mandiant di settembre 2026 che meriterebbe una cornice in ogni sala riunioni. Soprattutto in quelle dove qualcuno ha appena approvato il budget per il “copilot aziendale”. Descrive un caso reale: un attaccante ha dirottato la sessione attiva di un assistente AI di coding presso un fornitore SaaS non identificato. Da lì ha usato la sessione attiva dello sviluppatore per installare un infostealer tramite un pacchetto PyPI avvelenato. Poi ha rubato token OAuth di GitHub e distribuito il worm auto-propagante “Shai-Hulud” attraverso circa 100 repository interni.

Il risultato non è stato un incidente isolato. È stato un worm che ha automatizzato il furto di segreti dei repository e l’esfiltrazione programmatica del codice sorgente proprietario. Tradotto per chi deve spiegarlo al CdA lunedì mattina: il copilota ha consigliato la libreria avvelenata con lo stesso tono rassicurante di requests o pandas. E nessuno nella catena ha avuto un motivo tecnico per dubitarne.

In sintesi

  • Un assistente AI di coding dirottato ha usato la sessione autenticata dello sviluppatore per installare un infostealer da un pacchetto PyPI avvelenato. Da lì ha rubato token OAuth di GitHub e diffuso il worm Shai-Hulud su circa 100 repository interni.
  • Lo slopsquatting sfrutta i nomi di pacchetti inesistenti che i modelli linguistici “allucinano” in modo ricorrente: gli attaccanti li registrano su npm o PyPI e attendono.
  • Le contromisure sono note: niente token a lunga durata agli agenti, verifica delle dipendenze contro allowlist e hash, download solo da repository interni controllati.
  • Per la NIS2 (art. 24 D.Lgs. 138/2024) la sicurezza della catena di approvvigionamento è un obbligo attivo. La responsabilità arriva agli organi di amministrazione.

Slopsquatting: quando un’allucinazione diventa una dipendenza

Il meccanismo, per chi lavora davvero sul codice, non ha nulla di esoterico. Un modello linguistico non consulta un registro dei pacchetti quando suggerisce una dipendenza. Genera un nome statisticamente plausibile, coerente con i pattern visti in addestramento, senza verificarne l’esistenza reale. La ricerca indipendente lo quantifica con una precisione quasi imbarazzante. Nei test recenti su più LLM, quasi un pacchetto AI-raccomandato su cinque semplicemente non esiste. E i nomi allucinati non sono rumore casuale: si ripetono in modo consistente a fronte di prompt identici.

Questo è il punto che rende l’attacco scalabile e non artigianale: gli attaccanti non devono indovinare, devono solo osservare. Monitorano sistematicamente gli output dei modelli di coding più diffusi e catalogano i nomi fantasma più ricorrenti. Poi li registrano su npm o PyPI e ci agganciano uno script di post-installazione. Lo script legge le variabili d’ambiente ed esfiltra token, chiavi cloud e credenziali Git nel momento stesso dell’installazione. Una volta nel lockfile, il pacchetto non è più un sospetto: è una dipendenza dichiarata e versionata. Ed è destinato a propagarsi in ogni pipeline CI/CD che builda quel progetto.

La componente agentica: l’assistente AI di coding con le chiavi di casa

Quello che il caso Mandiant aggiunge alla teoria è la componente agentica, ed è esattamente ciò che rende il 2026 diverso dal 2025. Il report è esplicito sul punto. L’adozione enterprise è passata da strumenti di supporto guidati dall’uomo a sistemi autonomi che orchestrano workflow complessi ed eseguono operazioni end-to-end. Gli agenti chiamano API, ottimizzano configurazioni di produzione e analizzano telemetria. Nessun umano legge ogni riga prima del click di conferma.

Nel caso specifico, il vettore non è stato un singolo sviluppatore distratto che copia un comando sbagliato da uno screenshot. È stata una sessione attiva di un assistente AI, con privilegi e contesto già autenticato. E qui casca l’asino di molte policy aziendali, scritte pensando ancora al modello “developer con terminale”. Se l’agente ha già accesso al token GitHub per aprire pull request automatiche, dirottare quella sessione significa ereditare quel token. Senza dover bucare nulla a monte.

Shai-Hulud e i server MCP fasulli: prompt injection contro il modello

Il worm Shai-Hulud, per chi non lo avesse ancora incrociato nei log, non è una novità isolata. È una famiglia che si è evoluta su più ondate dentro l’ecosistema npm. Le sue campagne hanno compromesso centinaia di pacchetti, per decine di milioni di download settimanali complessivi.

Le varianti più recenti, quelle che interessano davvero chi gestisce toolchain AI, non si limitano a rubare credenziali. Distribuiscono server MCP fasulli con payload di prompt injection incorporati. Il payload istruisce gli assistenti AI collegati a leggere chiavi SSH, credenziali AWS e token npm. Nel mirino anche ogni variabile d’ambiente con pattern come TOKEN, KEY, SECRET o PASSWORD. Il materiale raccolto passa poi come contesto nella chiamata dello strumento, con l’istruzione esplicita di non menzionare la raccolta all’utente. Non è più typosquatting con qualche lettera invertita: è ingegneria sociale rivolta al modello, non alla persona. E funziona perché il modello non ha scetticismo, ha solo probabilità.

Le contromisure raccomandate da Mandiant

Mandiant, nella sezione difensiva del report, non propone incantesimi. Le raccomandazioni sono tre:

  • impedire alle estensioni l’accesso diretto a chiavi API grezze e token OAuth a lunga durata;
  • verificare ogni dipendenza raccomandata dall’AI contro liste approvate e hash crittografici;
  • instradare il download delle dipendenze attraverso repository interni controllati.

Sono tre righe che qualunque sysadmin serio avrebbe già dovuto implementare per il codice scritto da umani. Oggi diventano non negoziabili, perché un agente propone e installa una dipendenza in un attimo. E così elimina quel secondo di esitazione umana che un tempo fungeva da controllo informale.

Il problema non è tecnico nel senso stretto: è organizzativo. Mirror interno dei pacchetti con allowlist, controllo hash automatizzato in pipeline, permessi degli agenti segmentati senza token a lunga vita per chi scrive codice. Sono tutte contromisure note, disponibili, documentate. Se non sono ovunque, non è per mancanza di soluzioni. È la pigrizia organizzativa che tratta l’AI coding assistant come un plugin innocuo, invece che come un endpoint privilegiato con accesso diretto al repository.

NIS2 e D.Lgs. 138/2024: la supply chain AI è una responsabilità del board

Qui si innesta il capitolo normativo, ed è il momento di essere chiari: su questo girano ancora troppe slide fumose. L’articolo 24 del decreto 138/2024, che recepisce l’articolo 21 della NIS2, non chiede genericamente “abbi fornitori sicuri”. Impone un approccio multirischio che include esplicitamente la sicurezza della catena di approvvigionamento. Questo comprende i rapporti tra ciascun soggetto e i suoi fornitori diretti. E l’obbligo non si ferma al questionario pre-contratto. Si estende alla valutazione della qualità complessiva dei prodotti e delle pratiche di cybersicurezza dei fornitori, procedure di sviluppo sicuro comprese.

Dal punto di vista normativo, un pacchetto PyPI avvelenato installato tramite un assistente AI è esattamente un vettore lato fornitore. È ciò che l’articolo 24 chiede di gestire attivamente, non di subire sperando che il registro pubblico faccia pulizia da solo. E quando la gestione fallisce, non è il CISO a dover fornire spiegazioni creative al tavolo del board: è il board stesso. La responsabilità personale degli amministratori per le misure di gestione del rischio è parte integrante dell’impianto normativo. Non è un optional per gli enti particolarmente diligenti.

Il vero problema è organizzativo, non tecnico

Il divario che vedo ogni volta che entro in un’azienda italiana per un assessment, piccola o strutturata che sia, è sempre lo stesso. Chi decide il budget non ha mai visto un lockfile in vita sua. Chi il lockfile lo legge tutti i giorni non ha voce nelle decisioni su cosa installare come agente autonomo sulla workstation di sviluppo.

Il management approva il copilota perché, secondo la slide del vendor, aumenta la produttività del 30%. L’IT lo installa perché “tanto lo vogliono tutti”. Nessuno dei due si è mai chiesto se quell’agente ha accesso permanente a un token GitHub con scope di scrittura su cento repository. Non è negligenza individuale: è un sistema di incentivi che premia la velocità di adozione. E penalizza chi solleva obiezioni, percepite come frenate burocratiche. Poi arriva il report Mandiant di turno e si scopre che il worm non ha dovuto bucare nulla. Gli è bastato aspettare che qualcuno, umano o agente, si fidasse.

La domanda da portare in CdA

Scrivendo questo pezzo, non mi chiedo se la prossima azienda italiana che userà un copilota di coding senza allowlist delle dipendenze verrà colpita. La statistica sull’hallucination rate dei pacchetti e la scala delle campagne Shai-Hulud rendono la domanda retorica. Il punto vero è un altro. Il vostro assistente AI suggerirà la prossima dipendenza con la stessa disinvolta sicurezza della funzione di validazione perfetta appena scritta. A quel punto, chi in azienda ha davvero l’autorità — e il budget — per fermare quel comando prima che arrivi in produzione?

Domande frequenti

Cos’è lo slopsquatting?

È una tecnica di attacco alla supply chain del software. Gli attaccanti osservano i nomi di pacchetti inesistenti che i modelli linguistici suggeriscono in modo ricorrente. Li registrano su npm o PyPI e vi inseriscono uno script di post-installazione. Lo script esfiltra token, chiavi cloud e credenziali Git al momento dell’installazione.

Cosa è successo nel caso descritto da Mandiant?

Un attaccante ha dirottato la sessione attiva di un assistente AI di coding presso un fornitore SaaS. Tramite un pacchetto PyPI avvelenato ha installato un infostealer e rubato token OAuth di GitHub. Poi ha distribuito il worm Shai-Hulud su circa 100 repository interni, esfiltrando codice sorgente proprietario.

Come si protegge un’azienda che usa assistenti AI di coding?

Trattando l’agente come un endpoint privilegiato. Servono un mirror interno dei pacchetti con allowlist, un controllo hash automatizzato in pipeline CI/CD e la segmentazione dei permessi. E nessun token a lunga vita a un processo che scrive codice.

Cosa prevede la NIS2 per la sicurezza dei fornitori?

L’articolo 24 del D.Lgs. 138/2024 recepisce l’articolo 21 della Direttiva NIS2. Impone un approccio multirischio che include la sicurezza della catena di approvvigionamento. Richiede anche di valutare le pratiche di cybersicurezza dei fornitori, comprese le procedure di sviluppo sicuro. La responsabilità delle misure di gestione del rischio ricade sugli organi di amministrazione.

Come interviene ARTINLEX

Un incidente di supply chain che passa da un agente AI è insieme un problema tecnico, probatorio e di responsabilità. ARTINLEX affronta tutti e tre i piani con un unico team multidisciplinare. L’ethical hacking valuta l’esposizione della toolchain di sviluppo e dei permessi concessi agli agenti AI. La digital forensics ricostruisce l’incidente con metodo e catena di custodia. Le competenze legali coprono gli adempimenti NIS2 e la tutela degli organi di amministrazione.

La prima consulenza di 30 minuti è gratuita: contatta ARTINLEX.

Leggi anche

Fonti