Slopsquatting: quando le allucinazioni dell’AI diventano un attacco alla supply chain

Slopsquatting è il nome di una minaccia alla catena di fornitura del software nata insieme alla programmazione assistita dall’intelligenza artificiale: gli assistenti di codice suggeriscono talvolta pacchetti che non esistono, frutto di un’allucinazione del modello, e un attaccante può registrare quei nomi inventati nei repository pubblici riempiendoli di codice malevolo. Lo sviluppatore che si fida del suggerimento installa così, in piena buona fede, una libreria ostile. È un attacco che non sfrutta una vulnerabilità tecnica, ma la fiducia mal riposta nell’output di un modello.

Che cos’è lo slopsquatting

Il termine slopsquatting è stato coniato da Seth Larson, developer-in-residence per la sicurezza della Python Software Foundation, combinando l’idea di slop, l’output di scarsa qualità generato dall’AI, con la logica dello squatting, l’occupazione di un nome altrui. La meccanica è semplice. Un assistente come quelli integrati negli editor di codice, interrogato su come svolgere un certo compito, raccomanda di installare un pacchetto da un registro pubblico come PyPI per Python o npm per JavaScript. Se quel pacchetto non esiste davvero, perché il modello lo ha inventato, il nome resta disponibile: chiunque può registrarlo. Un attaccante che conosca i nomi più frequentemente allucinati li occupa in anticipo con pacchetti che contengono codice dannoso, in attesa che qualcuno li installi seguendo il consiglio dell’AI.

La differenza rispetto agli attacchi più noti è sottile ma importante. Nel typosquatting l’attaccante registra varianti con errori di battitura di pacchetti reali e diffusi; nello slopsquatting, invece, occupa nomi del tutto inventati ma plausibili, che nessun controllo ortografico segnalerebbe perché non imitano nulla di esistente. È un bersaglio creato dal modello, non dall’errore umano.

Quanto sono frequenti i pacchetti allucinati

Il fenomeno è stato quantificato da uno studio accademico presentato a USENIX Security 2025, intitolato We Have a Package for You! e condotto da ricercatori delle università del Texas a San Antonio, dell’Oklahoma e della Virginia Tech. Generando 576.000 campioni di codice con 16 modelli diversi in Python e JavaScript, i ricercatori hanno raccolto 2,23 milioni di pacchetti citati nelle risposte: di questi, il 19,7% (440.445) era inesistente, per un totale di 205.474 nomi di pacchetti fittizi unici, non presenti in alcun registro pubblico.

Il dato cambia molto a seconda del tipo di modello. I modelli commerciali si sono dimostrati più affidabili, con un tasso medio di allucinazione di almeno il 5,2% e con GPT-4 al 4,05%; i modelli open source hanno fatto molto peggio, con una media vicina al 21,7% e con alcune versioni di CodeLlama oltre il 33%. In altre parole, una porzione tutt’altro che marginale dei suggerimenti su quali librerie installare punta a qualcosa che non esiste, e quel vuoto è esattamente lo spazio che lo slopsquatting sfrutta.

Perché un modello inventa nomi di pacchetti? Perché genera testo statisticamente plausibile, non verificato: assembla nomi che somigliano a quelli reali, seguendo le convenzioni che ha visto in addestramento, senza alcun controllo sull’effettiva esistenza della libreria nel registro. Il risultato è spesso un nome verosimile, ben formato e coerente con il contesto, che proprio per questo lo sviluppatore tende a non mettere in dubbio. È la stessa qualità linguistica dell’output a renderlo pericoloso.

Perché funziona: la persistenza delle allucinazioni

Se le allucinazioni fossero casuali e irripetibili, l’attacco sarebbe poco pratico: un attaccante non potrebbe sapere quali nomi occupare. Lo studio dimostra invece il contrario. Rieseguendo dieci volte gli stessi prompt, il 43% dei nomi di pacchetto allucinati ricompariva a ogni singola esecuzione e il 58% si ripeteva più di una volta. Le allucinazioni, quindi, non sono rumore imprevedibile: sono in larga misura artefatti stabili e prevedibili del modo in cui i modelli rispondono a certe richieste.

Questa prevedibilità è ciò che rende lo slopsquatting un attacco realistico e non teorico. Un avversario può generare in massa suggerimenti di codice, raccogliere i nomi inventati che il modello produce in modo ricorrente e registrarli preventivamente. Il rischio cresce con la diffusione del cosiddetto vibe coding, la pratica di accettare e incollare il codice proposto dall’AI senza una verifica puntuale: quanto più ci si fida del suggerimento, tanto più il nome fantasma diventa una porta aperta.

Un caso reale: il pacchetto fantasma “huggingface-cli”

Che il rischio sia concreto lo ha dimostrato, già all’inizio del 2024, un esperimento del ricercatore Bar Lanyado di Lasso Security. Lanyado aveva notato che diversi modelli suggerivano con insistenza di installare un pacchetto Python chiamato huggingface-cli, mentre lo strumento reale si installa in modo diverso: quel nome breve, semplicemente, non esisteva. Per misurare il fenomeno, il ricercatore ha caricato su PyPI un pacchetto vuoto e innocuo con quel nome esatto. Nel giro di tre mesi ha collezionato oltre 30.000 download autentici, e si è scoperto che persino una grande azienda come Alibaba aveva inserito il comando di installazione del pacchetto inesistente nel file README di un proprio repository pubblico. Il pacchetto era inoffensivo perché a registrarlo era stato un ricercatore: se al suo posto ci fosse stato un attaccante, l’esito sarebbe stato una compromissione su larga scala. È la prova che lo slopsquatting non descrive un’ipotesi di laboratorio, ma un meccanismo già osservato sul campo prima ancora che gli venisse dato un nome.

Dal pacchetto fantasma all’attacco reale

La catena dell’attacco è lineare. Il modello allucina un nome credibile; l’attaccante lo registra su PyPI o npm con un pacchetto che, una volta installato, esegue codice arbitrario, ruba segreti o apre un accesso persistente; lo sviluppatore, fidandosi dell’assistente, esegue il comando di installazione e introduce la libreria ostile nel proprio ambiente e, a cascata, nelle applicazioni che la includono. Da lì il problema si propaga lungo tutta la catena di fornitura, esattamente come negli incidenti che colpiscono i pacchetti legittimi compromessi, di cui l’archivio di ICT Security Magazine ha raccontato la dinamica analizzando l’attacco a LiteLLM.

Lo slopsquatting può anche combinarsi con altre tecniche: se il nome allucinato coincide con quello di un pacchetto interno privato, l’attacco sfocia nella dependency confusion, in cui la versione pubblica malevola viene preferita a quella interna legittima. È la dimostrazione che i vettori della supply chain non si escludono, ma si sommano.

A rendere insidioso lo slopsquatting contribuisce anche la difficoltà di individuarlo. Il pacchetto malevolo non imita un nome esistente, quindi non emerge dai confronti con le librerie note; appare semplicemente come un pacchetto nuovo, con un nome plausibile, in un ecosistema dove ogni giorno se ne pubblicano a migliaia. Senza un controllo esplicito sulla reale provenienza e reputazione di ciò che si installa, non c’è alcun campanello d’allarme automatico a fermare l’installazione.

Come difendersi dallo slopsquatting

La prima difesa è culturale: non trattare i suggerimenti di un assistente AI come verità verificate. Ogni pacchetto proposto va controllato contro il registro ufficiale prima dell’installazione, verificandone esistenza, manutentore, storico delle versioni e diffusione reale. Sul piano dei processi, aiutano le pratiche già note della sicurezza della supply chain: fissare le dipendenze con file di lock e versioni pinnate, usare allowlist o mirror interni curati di pacchetti approvati, integrare strumenti di Software Composition Analysis (SCA, analisi della composizione del software) nelle pipeline e mantenere una distinta dei materiali software, l’SBOM, per sapere sempre cosa entra nelle applicazioni. Un riferimento utile in questo senso è il framework SLSA per l’integrità della catena di build.

Conviene inoltre automatizzare il controllo: agganciare alla pipeline e agli strumenti di sviluppo verifiche che blocchino l’installazione di pacchetti non presenti in un elenco approvato o privi di una reputazione consolidata, e preferire l’aggiunta esplicita delle dipendenze da parte di una persona rispetto all’esecuzione automatica dei comandi proposti dall’assistente.

Sul fronte del modello, la ricerca indica che far rileggere all’AI il proprio output, chiedendole di elencare e verificare i pacchetti citati, riduce gli errori; tecniche come il fine-tuning mirato e il RAG abbattono il tasso di allucinazione in modo significativo. Restano comunque misure di mitigazione: la responsabilità di validare ciò che si installa rimane di chi sviluppa.

Una superficie d’attacco destinata a crescere

Lo slopsquatting è un esempio limpido di come l’adozione dell’AI generi rischi di sicurezza inediti, non perché l’AI sia malevola, ma perché introduce nuovi punti di fiducia implicita. Con la diffusione degli agenti di codifica autonomi, capaci di installare dipendenze ed eseguire comandi senza supervisione passo passo, la finestra tra il suggerimento allucinato e l’esecuzione si restringe, e con essa il tempo per accorgersi dell’errore. Inserire la verifica delle dipendenze suggerite dall’AI nei controlli standard della supply chain, accanto alle difese contro typosquatting e dependency confusion, non è più una raffinatezza ma una necessità. Per le organizzazioni significa estendere alla catena di fornitura del software le stesse logiche di governo che si applicano agli altri asset: tracciare ciò che entra nelle applicazioni con un SBOM aggiornato, definire chi approva nuove dipendenze e trattare i suggerimenti dei modelli come input da validare, non come decisioni già prese. La regola di fondo resta quella di sempre, applicata a uno scenario nuovo: fidarsi è bene, verificare la provenienza del codice è meglio.