Slopsquatting: quando l’assistente AI installa un pacchetto che non esiste

Chiedi aiuto a un assistente AI e spesso ti suggerirà una libreria insieme al codice. Il più delle volte la libreria esiste. A volte no: il modello produce un nome che suona giusto, segue le convenzioni di denominazione dell’ecosistema e semplicemente non esiste su npm o PyPI. Se esegui il comando di installazione senza guardare, succede una di due cose. L’installazione fallisce, il che è fastidioso ma innocuo. Oppure qualcuno ha già pubblicato un pacchetto con esattamente quel nome, e tu hai appena eseguito il suo codice.

Cos’è lo slopsquatting

Slopsquatting è il nome di questo secondo caso: registrare nomi di pacchetti che i modelli AI tendono a inventare e aspettare che qualcuno li installi. Il termine viene di solito attribuito a Seth Larson, security developer-in-residence della Python Software Foundation, e gioca sul typosquatting, in cui gli attaccanti registrano varianti con errori di battitura di pacchetti popolari. La differenza sta in chi sbaglia. Nel typosquatting è una persona a digitare male. Nello slopsquatting è un modello a suggerire con sicurezza il nome sbagliato, e una persona a fidarsi.

Il rischio non è ipotetico. In un esperimento molto citato, un ricercatore si è accorto che i modelli continuavano a consigliare un pacchetto chiamato huggingface-cli, che non è il modo in cui si installa il vero tool di Hugging Face. Ha pubblicato un pacchetto vuoto con quel nome per vedere cosa sarebbe successo, e è stato scaricato decine di migliaia di volte. Il pacchetto era innocuo. Uno malevolo non lo sarebbe stato.

Quanto spesso i modelli inventano pacchetti

Lo studio più approfondito finora è “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”, presentato a USENIX Security 2025. Gli autori hanno generato 576.000 campioni di codice in Python e JavaScript con 16 modelli popolari e hanno controllato ogni pacchetto a cui il codice faceva riferimento. Hanno rilevato che la quota media di pacchetti allucinati era almeno del 5,2% per i modelli commerciali e del 21,7% per quelli open source, e hanno raccolto 205.474 nomi di pacchetti univoci che non esistevano.

Due dettagli dello studio contano più dei numeri principali. Primo, i nomi inventati sono spesso ripetibili: quando gli autori hanno rieseguito dieci volte i prompt che avevano prodotto un’allucinazione, il 43% di quei nomi è ricomparso ogni singola volta. Nomi prevedibili sono esattamente ciò che serve a un attaccante. Secondo, la maggior parte non è una storpiatura di pacchetti reali, quindi un controllo sui refusi non li intercetta. Solo il 13% circa distava uno o due caratteri da un nome esistente.

I modelli sono migliorati da allora, e gli assistenti che consultano il registry prima di suggerire un pacchetto rendono il problema più raro. Più raro però non significa scomparso, soprattutto per task di nicchia in cui il modello ha visto pochi esempi reali.

Perché l’attacco è praticabile

Pubblicare su npm o PyPI è gratuito e richiede pochi minuti. Un attaccante non deve compromettere nulla; deve solo indovinare i nomi che i modelli producono e registrarli per primo. Al resto pensano gli script di installazione: npm esegue di default gli script preinstall e postinstall, e un pacchetto Python può eseguire codice quando viene compilato o importato. Una singola installazione sul portatile di uno sviluppatore o su un runner di CI può esporre chiavi SSH, credenziali cloud e token nelle variabili d’ambiente.

Gli agent rendono il problema più acuto. Quando un assistente può eseguire da solo npm install o pip install, potrebbe non esserci nessun essere umano a guardare il nome del pacchetto.

Verificare un pacchetto in un minuto

Prima di aggiungere una dipendenza che non hai scelto tu, cercala nel registry:

# npm: does it exist, who publishes it, when was it first released?$ npm view some-package name version time.created repository.url # PyPI: same questions, from the JSON API$ curl -s https://pypi.org/pypi/some-package/json | jq '.info | {name, version, home_page, project_urls}'

Poi fatti qualche domanda veloce:

• Esiste davvero? Un 404 significa che il nome è stato inventato. Non crearlo, e non installare un’alternativa “abbastanza simile” senza verificare anche quella.
• È nuovissimo? Un pacchetto pubblicato per la prima volta nelle ultime settimane, con una sola versione e nessuno storico, merita una seconda occhiata, soprattutto se il nome coincide con quello suggerito dal tuo assistente.
• Rimanda a un progetto reale? Un repository collegato con commit, issue e altri utenti è un buon segno. Un repository vuoto o assente no.
• È il pacchetto che la documentazione ti dice di installare? La documentazione ufficiale del tool è la fonte migliore per il nome corretto. huggingface-cli rispetto al comando di installazione documentato è un buon esempio del perché.

Abitudini che aiutano

• Usa i lockfile e installa da quelli in CI (npm ci, pip install -r con versioni e hash fissati), così un nome nuovo non può infilarsi durante una build.
• Rivedi le modifiche alle dipendenze nelle pull request con la stessa cura delle modifiche al codice. Un diff che aggiunge tre pacchetti merita tre verifiche.
• Chiedi al tuo assistente di linkare la pagina del pacchetto nel registry o la documentazione ufficiale quando suggerisce qualcosa di nuovo. È un modo economico per far emergere un nome inventato.
• Se il tuo agent può eseguire installazioni in autonomia, dagli una allowlist o richiedi una conferma per le nuove dipendenze.
• Valuta di disattivare di default gli script di installazione (npm config set ignore-scripts true) e di abilitarli solo per i pacchetti che ne hanno bisogno. Alcuni pacchetti smettono di funzionare, quindi provalo prima.

Automatizzare la parte noiosa

Le verifiche manuali funzionano per un pacchetto. Non scalano a un repository con centinaia di dipendenze, né agli import sepolti nel codice che un assistente ha generato la settimana scorsa. È un lavoro adatto agli strumenti automatici.

La suite sui rischi del codice AI di vetkit cerca sui registry pubblici come npm e PyPI le dipendenze e gli import presenti nei tuoi manifest. Segnala i nomi che non esistono, le versioni mai pubblicate e i pacchetti rilasciati per la prima volta negli ultimi 30 giorni. Ai registry vengono inviati solo nomi e versioni dei pacchetti, mai il tuo codice sorgente, e i pacchetti provenienti da registry privati o dai tuoi workspace non vengono cercati. Anche il server MCP di vetkit espone un controllo dei pacchetti, così un assistente può verificare un nome prima di installare qualsiasi cosa.

Qualunque strumento tu usi, il principio è lo stesso: il nome di un pacchetto arrivato da un modello è un’affermazione, e le affermazioni costano poco da verificare prima di eseguirle.