Il problema in una frase
La prossima volta un L'assistente AI consiglia un pacchetto da installareHai intenzione di verificare effettivamente se quel pacchetto esiste? La maggior parte degli sviluppatori non lo fa. Quel divario tra suggerimento e verifica è proprio il punto di partenza degli attacchi di slopsquatting, ed è per questo che comprendere sia l'evoluzione dello slopsquatting sia le strategie pratiche per prevenirlo è diventata una vera priorità per i team di AppSec e DevSecOps.
Che cos'è un attacco di slopsquatting?
Un attacco di slopsquatting è una variante di typosquatting (la pratica di registrare un nome di dominio o di pacchetto che imita uno legittimo attraverso un errore di ortografia comune, come richieste invece di richieste(sperando che un errore di battitura dell'utente lo conduca direttamente a quel risultato), ma con un'importante differenza nell'origine dell'errore. Il typosquatting sfrutta gli errori di battitura umani. Un attacco di slopsquatting sfrutta gli errori commessi dai grandi modelli linguistici: un LLM "allucina" un nome di pacchetto che sembra perfettamente legittimo ma non esiste in alcun registro pubblico, e un attaccante lo ottiene per primo registrando esattamente quel nome prima che lo faccia chiunque abbia buone intenzioni.
Il meccanismo alla base di un tipico attacco di slopsquatting è semplice, ed è proprio questa semplicità a renderlo efficace:
- Uno sviluppatore chiede a un assistente basato sull'intelligenza artificiale di aiutarlo a risolvere un problema di programmazione.
- Il modello genera una soluzione che importa o consiglia di installare un pacchetto che non è mai esistito.
- Un malintenzionato che ha notato che diversi modelli continuano a ripetere lo stesso nome, peraltro inesistente, registra quel pacchetto su npm, PyPI o un altro registro pubblico, con del codice dannoso al suo interno. È in questo momento che l'allucinazione si trasforma in un vero e proprio attacco di slopsquatting.
- Il prossimo sviluppatore che riceve lo stesso suggerimento e non lo verifica, installa il pacchetto ormai reale, che funge da backdoor nel suo ambiente.
Il termine "slopsquatting" è stato coniato da Seth Larson, Security Developer-in-Residence presso la Python Software Foundation, e reso popolare da Andrew Nesbitt, per descrivere esattamente questo schema: un'“allucinazione da pacchetto” trasformata in un vettore di attacco.
L'evoluzione dello slopsquatting: come una curiosità di ricerca si è trasformata in una vera minaccia
Ciò che è degno di nota nell'evoluzione dello slopsquatting non è solo il concetto, ma la rapidità con cui è passato da un'osservazione di ricerca a una classe di attacco documentata e misurabile.
2023: Il primo segnale d'allarme. Bar Lanyado, ricercatore nel campo della sicurezza ho notato che diversi LLM hanno ripetutamente raccomandato un pacchetto chiamato abbracciandoface-cli, che non esiste (il pacchetto reale viene installato con pip install -U “huggingface_hub[cli]”Per dimostrare il rischio, caricò una versione vuota di quel pacchetto su un registro pubblico. Nel giro di tre mesi, aveva ricevuto oltre 30,000 download, senza alcuna promozione. Il nome inventato comparve persino nel README di un repository collegato a una ricerca di Alibaba, mostrando fin da subito come questi nomi "falsi" potessero infiltrarsi nella documentazione reale e preparare il terreno per gli attacchi di slopsquatting che sarebbero seguiti.
2024: Il rischio passa da un post sul blog di un ricercatore alla copertura mediatica mainstream del settore tecnologico. Nel marzo 2024, Il registro È stato riportato come i modelli di intelligenza artificiale stessero inventando con sicurezza nomi di pacchetti software che gli sviluppatori scaricavano, alcuni dei quali potenzialmente infettati da malware. Tale copertura mediatica era importante meno per ciò che rivelava a livello tecnico e più per ciò che segnalava: il caso huggingface-cli non era più una curiosità isolata; era il primo segnale di uno schema abbastanza grave da essere segnalato dalla stampa tecnologica mainstream, prima ancora del vasto studio accademico che ne avrebbe confermato la portata un anno dopo.
2025: La prima misurazione rigorosa e su larga scala del problema. Il documento “Abbiamo un pacco per te! Un’analisi completa delle allucinazioni del pacco da parte di LLM che generano codice” (Spracklen et al., presentato al Simposio sulla sicurezza USENIXSono stati testati 16 modelli di generazione di codice, sia commerciali (GPT-4, GPT-3.5) che open source (CodeLlama, DeepSeek, WizardCoder, Mistral), su 576,000 campioni di codice Python e JavaScript. I risultati segnano un punto di svolta nell'evoluzione dello slopsquatting, trasformandolo da aneddoto in dato:
- Il 19.7% dei pacchetti consigliati dalle modelle non esisteva.
- I modelli open-source hanno avuto allucinazioni molto più frequentemente (21.7% in media) rispetto ai modelli commerciali (5.2%).
- In tutti i modelli testati, i ricercatori hanno registrato oltre 205,000 nomi di pacchi allucinati unici, un insieme abbastanza ampio da alimentare attacchi di slopsquatting prolungati in molteplici ecosistemi.
Un dettaglio cruciale dello studio, e probabilmente il motivo per cui l'evoluzione dello slopsquatting si è accelerata anziché esaurirsi, è che i nomi inventati non sono casuali e non cambiano a ogni tentativo. Gli stessi modelli tendono a ripetere gli stessi nomi inventati quando vengono forniti input simili, il che significa che un attaccante non ha bisogno di tirare a indovinare. Deve solo osservare il comportamento del modello, identificare i nomi che si ripetono e registrarli prima che lo faccia uno sviluppatore reale. Un'analisi successiva di questa ripetibilità ha rilevato che quando i ricercatori hanno ripetuto gli stessi input dieci volte ciascuno, il 43% dei nomi di pacchetti inventati è apparso in ogni singola esecuzione, a dimostrazione che la maggior parte delle allucinazioni sono artefatti ripetibili piuttosto che rumore isolato. Questa ripetibilità è ciò che trasforma un'allucinazione isolata in un attacco di slopsquatting scalabile.
2026: Dai pacchetti isolati agli agenti autonomi. Dai pacchetti isolati agli agenti autonomi. Quest'anno ha fornito la prova più evidente che lo slopsquatting non si limita più al semplice copia-incolla da parte di uno sviluppatore di un comando di installazione tramite pip o npm. Nel gennaio 2026, il ricercatore di sicurezza Charlie Eriksen ha scoperto che agenti di programmazione basati sull'IA avevano già diffuso istruzioni che facevano riferimento a un pacchetto npm fittizio, react-codeshift (un nome che plausibilmente confonde due strumenti reali, jscodeshift e react-codemod), su 237 repository, e gli agenti continuavano a tentare di installarlo quotidianamente. Eriksen ha registrato il nome a scopo precauzionale, prima che un attaccante potesse utilizzarlo a fini malevoli. Separatamente, un pacchetto dannoso reale chiamato unused-imports, creato al posto del legittimo eslint-plugin-unused-imports, registrava ancora circa 233 download settimanali all'inizio del 2026, nonostante npm lo avesse bloccato per motivi di sicurezza: un segno di quanto a lungo un attacco di slopsquatting possa continuare ad attirare vittime anche dopo essere stato segnalato. Più recentemente, nel luglio 2026, i ricercatori hanno descritto una tecnica correlata, soprannominata "HalluSquatting", che collega un'allucinazione dell'IA con un'iniezione di prompt in modo che un agente di programmazione IA che recupera una risorsa allucinata per conto di un utente possa essere dirottato per eseguire codice fornito dall'attaccante, estendendo l'evoluzione dello slopsquatting da un rischio di installazione passivo a un vettore attivo di esecuzione di codice remoto all'interno dei flussi di lavoro di sviluppo agentivo.
Perché il “vibe coding” ha ampliato la superficie per gli attacchi di slopsquatting
Gli attacchi di slopsquatting non sarebbero un grosso problema se il codice generato dall'IA fosse una pratica di nicchia. Ma non lo è. L'ascesa degli assistenti di programmazione, degli agenti autonomi e dei flussi di lavoro di "vibe coding", in cui gli sviluppatori rivedono sempre meno codice prima di eseguirlo, ha modificato la superficie di attacco del software in due modi concreti, ed entrambi stanno accelerando l'evoluzione dello slopsquatting:
- Il punto di accesso non è più solo lo sviluppatore. Un attacco di typosquatting in passato dipendeva da un singolo errore di battitura. Ora l'errore può originarsi all'interno del modello stesso e propagarsi a centinaia di sviluppatori diversi che pongono domande simili e ricevono la stessa raccomandazione errata, moltiplicando la portata di un singolo attacco di slopsquatting.
- La superficie di attacco si è spostata più in alto nella catena. Non è più sufficiente osservare il codice scritto da un essere umano. I team devono anche monitorare le dipendenze suggerite da un assistente IA, i server MCP a cui si connette e gli agenti che installano i pacchetti autonomamente senza una revisione umana diretta. La sicurezza delle applicazioni tradizionale, progettata per esaminare i repository e gli utenti umani commits non è mai stato progettato per osservare questa nuova interazione tra sviluppatore, IA e registro dei pacchetti, che è esattamente il luogo in cui ora si nascondono gli attacchi di slopsquatting.
Tutto ciò non significa che l'IA generativa sia intrinsecamente insicura. Significa piuttosto che introduce un nuovo tipo di rischio nella catena di fornitura che gli strumenti di sicurezza tradizionali non sono stati progettati per rilevare, e che richiede gli stessi principi di verifica che già applichiamo a qualsiasi dipendenza esterna: non fidarsi a priori, verificare la fonte e automatizzare tale verifica anziché affidarsi alla memoria o alla vigilanza di ogni singolo sviluppatore. Questa automazione è il fondamento di qualsiasi strategia efficace per prevenire l'appropriazione indebita di risorse.
Prevenzione dell'occupazione abusiva di terreni: cosa possono fare oggi le squadre
La buona notizia è che la prevenzione dello slopsquatting non richiede strumenti esotici. Richiede l'applicazione sistematica di pratiche di gestione delle dipendenze già esistenti, ma che molti team tendono a trascurare non appena un'IA di cui si fidano "suggerisce" il codice. Un approccio efficace alla prevenzione dello slopsquatting solitamente combina i seguenti elementi:
- Verifica manualmente ogni nuovo pacchetto prima di installarlo., soprattutto se il suggerimento proviene da un assistente IA. Verificate che esista nel registro ufficiale, chi lo gestisce, quando è stato pubblicato e se il numero di download sembra reale. Questa semplice abitudine è il metodo più economico per prevenire l'accaparramento di risorse a disposizione di qualsiasi team.
- Non bisogna mai dare per scontato che il codice generato dall'IA sia sicuro di default. Un frammento di codice che "funziona" non significa che le sue dipendenze siano legittime. La verifica delle dipendenze dovrebbe essere parte integrante della revisione del codice, non un'eccezione.
- Utilizzare file di blocco e verifica hash per bloccare le versioni esatte e impedire che un aggiornamento silenzioso installi un pacchetto diverso da quello originariamente verificato.
- Implementare la scansione delle dipendenze che segnala modelli di rischio al di là delle CVE notePacchetti anomali, nomi sospettosamente simili a quelli esistenti, nuovi manutentori senza esperienza pregressa o script di installazione con comportamenti insoliti. Un pacchetto appena pubblicato, praticamente inesistente, che imita da vicino il nome di qualcosa di "quasi" familiare, è esattamente lo schema alla base della maggior parte degli attacchi di slopsquatting documentati finora.
- Trattare i registri pubblici con lo stesso scetticismocism come qualsiasi altra fonte esterna non verificata. Il fatto che installazione pip or installazione di npm Il fatto che non generi un errore non è prova di legittimità.
- Formare i team di sviluppo sul fatto che la programmazione assistita dall'IA non elimina la responsabilità di verificare ciò che viene installato; aggiunge semplicemente un passaggio che deve essere integrato nel flusso di lavoro come parte di qualsiasi serio piano di prevenzione dell'occupazione abusiva di immobili.
Nessuna di queste misure è nuova di per sé. Ciò che è cambiato è la scala: quando un suggerimento di dipendenza non proviene più da Stack Overflow o da un collega, ma da un modello in grado di ripetere lo stesso errore immaginario a migliaia di sviluppatori diversi, la verifica manuale, pur essendo ancora necessaria, smette di essere sufficiente da sola. Ecco perché sempre più team stanno automatizzando questo livello di prevenzione dello slopsquatting all'interno dei loro Analisi della composizione del software (SCA) utensili, piuttosto che lasciare la questione alla disciplina del singolo sviluppatore.
Questo è precisely perché ASPM piattaforme come Xygeni integrare il rilevamento di dipendenze sospette, che comprende typosquatting, confusione di dipendenze e pacchetti dannosi noti, nella stessa analisi delle dipendenze open source e basata sull'IA. pipelinePertanto, la prevenzione dello slopsquatting non dipende dal fatto che ogni sviluppatore si ricordi di controllarla ogni volta che un assistente IA suggerisce una nuova dipendenza.
FAQ
Un attacco di slopsquatting è la stessa cosa di un attacco di typosquatting?
Non proprio. Entrambi i tipi di attacco prevedono la registrazione di un nome di pacchetto falso per ingannare chi lo installa, ma la fonte dell'errore è diversa. Il typosquatting sfrutta gli errori di digitazione umani. Un attacco di slopsquatting, invece, sfrutta nomi di pacchetto inventati (o forse frutto di allucinazioni) da modelli di intelligenza artificiale, che un aggressore registra prima ancora che esistano realmente.
Un gestore di pacchetti può prevenire automaticamente questo tipo di attacco?
Non del tutto, ed è proprio per questo che la prevenzione dello slopsquatting non può fermarsi al livello del gestore di pacchetti. Se un malintenzionato registra il pacchetto fasullo prima che uno sviluppatore tenti di installarlo, l'installazione si completerà senza errori perché il pacchetto esiste realmente, anche se è dannoso. Una prevenzione efficace richiede un'ulteriore verifica dell'origine e del comportamento del pacchetto.
Questo riguarda solo i modelli open-source?
No. Lo studio di Spracklen et al. ha riscontrato allucinazioni in tutti i modelli testati, compresi quelli commerciali, sebbene con una frequenza significativamente inferiore (5.2% contro il 21.7% per i modelli open-source valutati). Nessun modello è completamente esente da questo problema, ed è anche per questo che l'evoluzione dello slopsquatting procede di pari passo con la crescita della programmazione assistita dall'IA in generale.
Si tratta di un rischio teorico o è già stato sfruttato?
Migliori abbracciandoface-cli Il caso di un pacchetto vuoto caricato da un ricercatore e scaricato più di 30,000 volte in tre mesi senza alcuna promozione dimostra che il rischio non è solo teorico: un nome inventato deve essere sufficientemente coerente in diverse richieste perché qualcuno possa trasformarlo in un vero e proprio attacco di slopsquatting.
