--- type: Blog Post title: Proteggere la supply chain degli agenti IA description: Come il worm npm Miasma del giugno 2026 ha aggirato le difese — più una checklist in 7 punti per proteggere la pipeline di agenti IA. resource: "https://www.contextstudios.ai/it/blog/proteggere-la-supply-chain-degli-agenti-ia" tags: [Sicurezza, Agenti IA, Supply chain, DevSecOps] language: it timestamp: "2026-06-25T07:26:17.138Z" --- # Proteggere la supply chain degli agenti IA All'inizio di giugno 2026 un worm capace di propagarsi da solo ha attraversato il registro npm e messo fuori uso decine di repository Microsoft in meno di due minuti. La campagna, denominata Miasma, non puntava agli esseri umani, bensì alle catene di dipendenze automatizzate che gli agenti di codifica basati sull'IA eseguono ormai per conto suo. Se il suo ambiente installa pacchetti senza che una persona rilegga ogni modifica, il problema la riguarda direttamente.
Un attacco alla supply chain degli agenti IA compromette le dipendenze open source, le fasi di compilazione e i file di configurazione di cui gli agenti di codifica autonomi si fidano per impostazione predefinita. Nel giugno 2026 il worm Miasma si è diffuso tramite npm eseguendo codice già in fase di installazione, colpendo Red Hat, Microsoft Azure e il framework di agenti IA Mastra prima che la maggior parte dei team se ne accorgesse.
Questa è una guida al rafforzamento pensata per chi sviluppa, non un riepilogo di cronaca. Di seguito troverà che cosa è accaduto davvero, perché l'attacco aggira le protezioni su cui la maggior parte dei team fa affidamento e quale elenco di controlli concreto può applicare già oggi alla propria catena. Che cosa è stata davvero l'ondata Miasma
Miasma è un worm npm capace di autopropagarsi che ha compromesso 57 pacchetti distribuiti su oltre 286 versioni malevole in meno di due ore, sottraendo credenziali e ripubblicandosi attraverso ogni account di manutentore conquistato.
Secondo StepSecurity, la prima ondata ha compromesso 57 pacchetti npm distribuiti su oltre 286 versioni malevole, nel corso di una campagna continua durata meno di due ore (StepSecurity). Nei giorni successivi si è ampliata in modo netto. Orca Security ha riferito che 32 pacchetti npm ufficiali @redhat-cloud-services sono stati compromessi da un worm che ruba credenziali e si avvia automaticamente durante l'installazione (Orca Security). Phoenix Security ha documentato l'arrivo del worm in Microsoft: la Azure Functions Action e altri 72 repository sono stati disattivati in circa 105 secondi, a cui si aggiungono 37 pacchetti PyPI colpiti (Phoenix Security). A metà giugno Aikido contava 141 pacchetti compromessi del framework di agenti IA Mastra, nei quali era stata iniettata una dipendenza malevola (Aikido). Gli esperti di sicurezza classificano Miasma come una variante della stirpe di worm Shai-Hulud (Phoenix Security). L'aspetto più istruttivo è proprio lo schema: da un token di manutentore compromesso nasce il furto di credenziali, da questo una ripubblicazione automatica, da questa il token compromesso successivo. Nessun essere umano decide nemmeno uno di questi passaggi. Perché l'attacco ha aggirato le protezioni che lei già possiede
Il worm Miasma eseguiva il proprio codice già in fase di installazione, tramite il file di compilazione binding.gyp di node-gyp, e non tramite gli script preinstall o postinstall che la maggior parte degli scanner sorveglia. Un pacchetto appariva quindi pulito fino al momento della compilazione.
La maggior parte dei team dà per scontato che il codice npm malevolo risieda negli hook preinstall o postinstall. Snyk ha documentato che Miasma eseguiva invece il proprio codice durante l'installazione, tramite binding.gyp e node-gyp, ossia attraverso il percorso di compilazione nativa, eludendo così l'ispezione degli script su cui si basano molti strumenti e molti sviluppatori (Snyk). Un pacchetto può superare un confronto del file di blocco e un audit degli script e impadronirsi comunque della sua macchina nel momento stesso in cui viene compilato. La fiducia basata sulla provenienza diventa ancora più fragile. Unit 42, la divisione di ricerca di Palo Alto Networks, ha riferito di tecniche di accesso iniziale, in questa ondata, che non richiedono alcuna credenziale rubata, oltre ai primi pacchetti npm malevoli dotati di provenienza SLSA valida (Unit 42). Se aveva adottato le attestazioni SLSA come un via libera, quel segnale da solo non basta più. È l'agente stesso ad amplificare il rischio. StellarCyber descrive l'escalation successiva: gli aggressori usano agenti interni compromessi per avviare richieste dall'interno, aggirando così la diffidenza che i team riservano di norma alle comunicazioni esterne (StellarCyber). Un agente autonomo che apre una richiesta di unione per «ottimizzare le dipendenze» gode di fiducia proprio perché appartiene a lei. È questa fiducia a costituire la superficie d'attacco. Abbiamo già spiegato come verificare ciò che gli agenti possono effettivamente fare; questa ondata mostra perché tale verifica non può essere facoltativa. Come il worm raggiunge la sua catena di agenti
Un worm della supply chain raggiunge una catena di agenti IA quando un agente installa una dipendenza compromessa, il pacchetto esegue codice durante l'installazione, quel codice sottrae il token del registro presente nell'ambiente e il worm si ripubblica sulla serie successiva di pacchetti, senza che nessun essere umano abbia rivisto una singola modifica.
Conviene seguire il ciclo dall'inizio alla fine, perché la difesa si colloca in un anello preciso. Per prima cosa un aggressore conquista il token di pubblicazione di un manutentore; Unit 42 ha rilevato varianti di questa ondata che non richiedevano alcuna credenziale rubata, il che non fa che accorciare questo passaggio (Unit 42). In secondo luogo il worm pubblica una versione correttiva manomessa di un pacchetto molto diffuso. In terzo luogo la sua catena, o un agente che vi opera, avvia un'installazione e preleva quella versione perché un intervallo di versioni flessibile lo consentiva. In quarto luogo il codice malevolo viene eseguito durante la fase di compilazione nativa, e non tramite un hook di script, ragione per cui un audit degli script lo ha lasciato passare (Snyk). In quinto luogo raccoglie tutte le credenziali presenti nell'ambiente, esattamente il comportamento che Orca ha osservato nei pacchetti Red Hat (Orca Security). Infine si ripubblica con quei token rubati, e il ciclo ricomincia. Ognuno di questi passaggi è automatizzabile, ed è per questo che StepSecurity ha misurato 57 pacchetti compromessi in meno di due ore nella prima ondata. Una persona inserita in quel ciclo rappresenta un attrito che il worm non riesce a modellare. L'elenco di controlli che segue non è in fondo che un insieme di punti in cui reintrodurre quell'attrito a basso costo. L'elenco di controlli per il rafforzamento, per chi sviluppa
Per rafforzare una catena di agenti IA contro i worm della supply chain: blocchi e verifichi le dipendenze tramite un file di blocco, disattivi per impostazione predefinita gli script di compilazione e di ciclo di vita durante l'installazione, isoli le installazioni degli agenti in un ambiente protetto e richieda un'approvazione umana per ogni modifica alle dipendenze proposta da un agente.
Applichi questi punti al suo ambiente. Nessuno di essi richiede un nuovo fornitore. 1. Blocchi tutto, verifichi con un file di blocco congelato. Gli intervalli di versioni flessibili lasciano che una versione correttiva pubblicata dal worm la raggiunga alla prossima installazione. Blocchi versioni esatte e faccia fallire l'integrazione continua a ogni scostamento del file di blocco. 2. Disattivi per impostazione predefinita gli script di ciclo di vita e di compilazione. Imposti ignore-scripts=true (npm) o l'equivalente e autorizzi in modo esplicito i pochi pacchetti che hanno davvero bisogno di compilazioni native. Così neutralizza sia il percorso di esecuzione postinstall sia quello binding.gyp. 3. Installi in un ambiente protetto, non sulla macchina dello sviluppatore. Assegni ai suoi agenti e agli esecutori dell'integrazione continua un ambiente effimero, con accesso di rete limitato e privo di credenziali permanenti. Un worm che si esegue durante l'installazione deve finire in un contenitore distrutto pochi minuti dopo, senza alcuna via di ritorno verso il suo registro o il suo cloud. Anche il filtraggio del traffico in uscita conta qui: un carico dannoso che non può né comunicare verso l'esterno né caricare una nuova versione non prolunga il ciclo, nemmeno se viene eseguito. 4. Rimuova i segreti dal contesto di installazione. Il furto di credenziali funziona solo se sono presenti credenziali. Tenga i token del registro, le chiavi cloud e i segreti dell'integrazione continua fuori da qualsiasi ambiente in cui vengono eseguite installazioni non affidabili. 5. Faccia di una persona il punto di approvazione per le modifiche alle dipendenze. Ogni modifica prodotta da un agente che tocchi package.json, un file di blocco o una configurazione di compilazione passa per una revisione umana obbligatoria. È l'unico controllo che l'intera ondata è stata progettata per aggirare. È la stessa disciplina del confine di fiducia che dovrebbe già regolare i permessi di scrittura degli agenti. 6. Esamini i file di configurazione impiantati nei repository duplicati o clonati. Tratti la configurazione di agente sotto controllo di versione, ossia tutto ciò che carica automaticamente istruzioni in un agente di codifica, come codice eseguibile. La riveda a ogni duplicazione e a ogni clonazione, prima che un agente la legga. 7. Non affidi il giudizio a un solo scanner. Endor Labs osserva che l'analisi statica basata su regole non riesce a stare al passo con gli schemi prodotti dagli assistenti IA e che serve un'analisi assistita dall'IA per individuare i rischi propri dell'IA (Endor Labs). Usi pure questi strumenti, ma li affianchi al punto di approvazione umano descritto sopra. Il filo conduttore: la velocità senza un punto di controllo è la vulnerabilità. Quella stessa disciplina ingegneristica che distingue il vero lavoro con gli agenti dal coding a intuito è ciò che impedisce a un worm capace di autopropagarsi di amplificarsi nella sua catena nel giro di una notte. Che cosa significa per i team nativi nell'IA
La lezione dell'ondata sulla supply chain del 2026 è questa: l'automazione elimina il ritardo umano che un tempo gli aggressori dovevano affrontare, perciò i team nativi nell'IA devono reintrodurre un punto di controllo umano deliberato esattamente dove un agente autonomo altrimenti agirebbe.
La constatazione scomoda è che la storia della produttività e quella del rischio coincidono. Un agente che installa dipendenze, apre richieste di unione e integra il proprio lavoro è veloce perché nessuna persona interviene, ed è proprio questo ritardo assente che un worm sfrutta per diffondersi prima che qualcuno riveda una modifica. Non lo si risolve rallentando ogni agente, bensì collocando un punto di controllo umano deliberato nel passaggio a maggiore impatto: l'integrazione delle dipendenze. Se costruisce catene di agenti che vuole rapide e difendibili, è esattamente il lavoro di architettura per cui il nostro team affianca le aziende. La governance a livello di esecuzione, tema delle recenti pubblicazioni sulla governance degli ambienti di esecuzione degli agenti, sta diventando un requisito di base, non un optional. Domande frequenti Che cos'è un attacco alla supply chain degli agenti IA? È un attacco che compromette i pacchetti open source, le fasi di compilazione o i file di configurazione che gli agenti di codifica autonomi installano e di cui si fidano automaticamente. Nel giugno 2026 il worm Miasma si è diffuso tramite npm e ha colpito Red Hat, Microsoft Azure e il framework Mastra (Aikido). Come ha fatto il worm Miasma a sfuggire al rilevamento? Eseguiva il proprio codice durante l'installazione tramite binding.gyp e node-gyp, e non tramite gli script preinstall/postinstall che la maggior parte degli scanner sorveglia, così i pacchetti apparivano puliti fino alla compilazione (Snyk). La provenienza SLSA mi protegge da tutto questo? Non da sola. Unit 42 ha segnalato i primi pacchetti npm malevoli dotati di provenienza SLSA valida, perciò l'attestazione resta necessaria, ma non è più un segnale sufficiente di sicurezza (Unit 42). Perché gli agenti di codifica IA sono un bersaglio più importante? Gli agenti installano e integrano modifiche con la fiducia propria dell'organizzazione, aggirando la diffidenza riservata alle fonti esterne, il che permette a un worm di diffondersi prima che una persona lo riveda (StellarCyber). Qual è il controllo più importante? Una revisione umana obbligatoria di ogni modifica prodotta da un agente che tocchi package.json, i file di blocco o le configurazioni di compilazione. È l'unico punto di controllo che l'intera ondata è stata progettata per aggirare. Conclusione L'ondata Miasma non è stata un evento isolato: è stata un'anteprima di come funzionano gli attacchi alla supply chain quando difensore e aggressore si muovono entrambi alla velocità della macchina. La difesa non consiste in maggiore automazione. Consiste in un punto di controllo umano ben collocato nel momento dell'integrazione delle dipendenze, in un ambiente di installazione dove non c'è nulla da rubare e nella disciplina di trattare ogni file affidato a un agente come codice eseguibile. Nessuno di questi controlli rallenta il lavoro che un agente svolge bene; interrompe soltanto l'unico passaggio di cui un worm ha bisogno per diffondersi. Lo predisponga adesso, finché è un elenco di controlli e non un incidente. Fonti 1. StepSecurity — Miasma npm Supply Chain Attack: Self-Spreading Worm 2. Snyk — Node-gyp Supply Chain Compromise 3. Orca Security — Red Hat npm Supply Chain Attack 4. Phoenix Security — Miasma: Azure Hit, 73 Repos Down, 37 PyPI 5. Phoenix Security — Miasma: Red Hat npm, variante Shai-Hulud 6. Aikido — Pacchetti npm Red Hat e Mastra compromessi 7. Unit 42 — Monitoring npm Supply Chain Attacks 8. StellarCyber — Top Agentic AI Security Threats in Late 2026 9. Endor Labs — AI Risk Reduction: Mitigation Strategies for 2026 10. The Hacker News — Miasma Compromises Red Hat npm Packages 11. Cloud Security Alliance — Miasma npm Supply Chain Research Note