L’impiego di assistenti di programmazione basati sull’intelligenza artificiale sta introducendo una nuova vulnerabilità nella catena di fornitura del software. Il fenomeno è stato definito “slopsquatting” e sfrutta la capacità dei modelli linguistici di suggerire pacchetti e librerie inesistenti all’interno del codice generato.
Durante la produzione di uno script, un modello può inserire un comando import, una dipendenza npm oppure un’istruzione pip install contenente un nome plausibile ma non associato ad alcun progetto reale. La denominazione inventata può sembrare coerente con le convenzioni utilizzate nei repository pubblici e con la funzione richiesta dal programmatore. Se lo sviluppatore esegue il comando senza verificare l’origine della dipendenza, inizialmente ottiene soltanto un errore perché il pacchetto non esiste.
Lo slopsquatting trasforma questo errore apparentemente innocuo in un possibile attacco. Un soggetto malevolo può interrogare ripetutamente gli strumenti di generazione del codice, individuare i nomi fittizi proposti con maggiore frequenza e registrarli su repository come PyPI o npm. A quel punto, una successiva raccomandazione dello stesso pacchetto non conduce più a una dipendenza inesistente, ma al download di codice controllato dall’attaccante.
La tecnica presenta una differenza sostanziale rispetto al typosquatting. Nel typosquatting viene pubblicato un pacchetto con un nome molto simile a quello di una libreria conosciuta, confidando in un errore di digitazione dell’utente. Nello slopsquatting il nome non deriva necessariamente da una svista umana: è il modello generativo a produrlo e a presentarlo come una componente software autentica. L’attaccante non deve quindi imitare una dipendenza specifica, ma occupare preventivamente uno spazio nominale creato dall’AI.
Il rischio è reso più concreto dalla ripetibilità delle allucinazioni. Un’analisi condotta su 16 modelli, 576.000 campioni di codice Python e JavaScript e due differenti raccolte di prompt ha rilevato oltre 205.000 nomi unici di pacchetti inesistenti. La percentuale media di dipendenze inventate ha raggiunto almeno il 21,7% nei modelli open source e il 5,2% nei modelli commerciali. In ulteriori verifiche, una parte consistente dei nomi fittizi è ricomparsa più volte sottoponendo al modello la medesima richiesta. Questa prevedibilità consente agli aggressori di concentrare la registrazione sui nomi con maggiori probabilità di essere suggeriti nuovamente.
Un pacchetto pubblicato con questa tecnica può contenere funzioni per il furto di credenziali, token di accesso, chiavi API e variabili d’ambiente. Può inoltre modificare i file del progetto, installare ulteriori componenti oppure eseguire codice durante le fasi di installazione e compilazione. La compromissione può propagarsi oltre il computer dello sviluppatore se la dipendenza viene inserita nei file di configurazione, nei repository aziendali o nelle pipeline di integrazione e distribuzione continua.
Gli agenti di coding autonomi amplificano ulteriormente il problema perché possono non limitarsi a suggerire la dipendenza. Se dispongono dell’accesso al terminale, possono installarla, aggiornare il manifest del progetto ed eseguire test o comandi di build. Una singola allucinazione può così passare direttamente dalla risposta del modello all’ambiente di sviluppo, soprattutto nei flussi di “vibe coding” caratterizzati da una revisione manuale ridotta.
La protezione richiede che ogni dipendenza proposta dall’AI venga trattata come un elemento non verificato. Prima dell’installazione è necessario controllare l’esistenza del progetto, l’identità del manutentore, la data di pubblicazione, la cronologia delle versioni, il repository sorgente e la documentazione. Un pacchetto appena registrato, privo di attività precedente o con una denominazione insolitamente aderente alla richiesta rivolta al modello deve essere considerato sospetto.
Nei processi aziendali, i controlli possono essere applicati attraverso repository interni, liste di dipendenze autorizzate, scanner della supply chain, analisi dei comportamenti eseguiti dagli script di installazione e blocco automatico dei pacchetti appena pubblicati o privi di reputazione. Lock file, versioni fissate e verifica degli hash impediscono inoltre che una build risolva autonomamente componenti differenti da quelli già controllati.
Lo slopsquatting mostra come l’affidabilità del codice generato non possa essere valutata soltanto dal punto di vista sintattico o funzionale. Un programma può essere formalmente corretto e superare i test, ma dipendere da un componente scelto sulla base di un’informazione inventata. L’integrazione degli assistenti AI nello sviluppo deve quindi includere una validazione esplicita delle dipendenze, separando la capacità del modello di produrre codice plausibile dalla verifica dell’esistenza e dell’affidabilità dei componenti che propone.