IA‑Code: i rischi del slopsquatting e le contromisure

Introduzione al fenomeno slopsquatting

Il rapido sviluppo di strumenti di programmazione assistiti dall’intelligenza artificiale, inclusi quelli classificati sotto la voce Vibe Coding, ha portato a un aumento significativo di nuove minacce basate sull’IA per la catena di fornitura del software.

Mentre gli assistenti di codifica IA accelerano il processo di sviluppo per i professionisti IT, la stessa tecnologia può essere sfruttata dagli aggressori per creare nuovi vettori di attacco. È proprio questo il caso dello slopsquatting. In un attacco di questo tipo, un pacchetto software viene registrato con un nome generato da un modello IA e, successivamente, si attende che un sviluppatore o un agente IA lo installi.

Lo slopsquatting non è un semplice KI‑slop o un Vibe Slop, ma una tattica più mirata e per sua natura più pericolosa. Mentre i KI‑slop e i Vibe Slop sono spesso prodotti collaterali casuali di un uso incontrollato dell’IA, lo slopsquatting è una strategia consapevole che utilizza l’IA per introdurre un nuovo tipo di rischio nella catena di fornitura del codice.

Origini del termine e contesto storico

Il termine è stato coniato dal ricercatore di sicurezza Seth Larson, Developer‑in‑Residence presso la Python Software Foundation, nell’aprile 2025, sebbene il comportamento sottostante fosse stato osservato già nel 2023. Lo slopsquatting combina il concetto di “AI slop” – risultati di bassa qualità generati dall’IA – con la pratica più vecchia del typosquatting, una tecnica in cui un nome simile a quello di un prodotto legittimo viene usato per ingannare l’utente.

Il typosquatting è una tecnica impiegata da decenni, soprattutto nei phishing, dove un dominio apparentemente affidabile induce gli utenti a cliccare su link dannosi. Lo slopsquatting, invece, si basa sulla capacità dell’IA di “inventare” nomi di pacchetti che sembrano plausibili ma non esistono.

Che cosa è lo slopsquatting?

Lo slopsquatting rappresenta un rischio crescente per gli strumenti di programmazione basati sull’IA. Le moderne metodologie di sviluppo si fondano su pacchetti di applicazione e di codice, che forniscono framework e funzioni necessarie alla creazione di software. Gli strumenti di codifica IA a volte inventano nomi di pacchetti, suggerendo dipendenze che non sono mai state pubblicate.

Sia gli sviluppatori umani sia gli agenti IA tendono a installare questi pacchetti senza verificare preventivamente la loro legittimità, aprendo la porta a potenziali compromissioni.

Meccanismo di funzionamento

Gli aggressori sfruttano il comportamento dell’IA per condurre attacchi di “package‑hallucination”.

«Analizzano i pattern nelle uscite dei grandi modelli linguistici (LLM), identificano i nomi di pacchetti fantasma che ricompaiono e li registrano in anticipo su gestori di pacchetti e registri online, inserendo payload dannosi», spiega Shane Barney, Chief Information Security Officer di Keeper Security. «Quando lo sviluppatore esegue il comando di installazione, il payload è già presente.»

La frequenza delle hallucinationi nei nomi dei pacchetti può essere quantificata. In un contributo presentato a USENIX Security 2025, ricercatori dell’University of Texas at San Antonio, dell’University of Oklahoma e della Virginia Tech hanno analizzato 16 modelli di generazione di codice e hanno scoperto che il 19,7 % dei pacchetti suggeriti non esisteva realmente. Inoltre, il 43 % dei nomi hallucinate è ricomparso in ogni singola esecuzione, quando gli stessi prompt sono stati ripetuti dieci volte.

Confronto tra typosquatting e slopsquatting

Nel typosquatting l’attaccante conta sul fatto che un umano commetta un errore di battitura o venga indotto in errore. Nel slopsquatting, invece, l’attaccante conta sul fatto che un modello IA generi un nome inesistente. Gli studi di USENIX hanno rilevato che solo il 13,4 % dei nomi inventati differisce di uno o due caratteri da un pacchetto reale, dimostrando che la maggior parte delle “illusioni” è completamente nuova.

Impatto e rischi per le organizzazioni

Lo slopsquatting è considerato uno dei rischi più urgenti nella programmazione IA per le seguenti ragioni:

• Svelta adozione dell’IA. Quasi tutte le aziende utilizzano IA per la programmazione, creando una vasta superficie di attacco. Gartner prevede che entro il 2028 il 90 % degli sviluppatori aziendali impiegherà assistenti di codice IA, estendendo il rischio a quasi ogni roadmap di sviluppo.
• Espansione della catena di fornitura. Un pacchetto non è solo un blocco di codice isolato; viene riutilizzato in numerose applicazioni, amplificando la minaccia. Un pacchetto compromesso può diffondersi a centinaia o migliaia di applicazioni che ne dipendono.
• Rischio reputazionale e finanziario. Una dipendenza compromessa in produzione può causare vulnerabilità sfruttabili o violazioni di dati, con conseguenti sanzioni per non conformità e obblighi di notifica ai clienti.
• Pressioni normative. Il Cyber Resilience Act dell’UE introduce nuove regole di segnalazione e gestione delle vulnerabilità. Inoltre, il memorandum M‑26‑05 del 2026 dell’Office of Management and Budget (OMB) negli USA ha trasformato la certificazione SBOM in un approccio basato sul rischio.
• Difficoltà di rilevamento. Gli scanner tradizionali non individuano le minacce generate da hallucinationi IA, poiché il pacchetto malevolo è spesso nuovo e non una versione modificata di un pacchetto già noto. Come osserva Trey Ford, Chief Strategy and Trust Officer di Bugcrowd, «Questo rischio non compare nei report al consiglio di amministrazione né nei questionari di audit per le cyber‑assicurazioni, perché non rientra in alcuna categoria esistente.»
• Conferma della realtà della minaccia. Nel gennaio 2026 il ricercatore di sicurezza Charlie Eriksen ha scoperto un caso concreto di slopsquatting che ha colpito diversi progetti open‑source, dimostrando la praticabilità dell’attacco.

Strategie di difesa e contromisure

Per mitigare il rischio di slopsquatting, le organizzazioni dovrebbero adottare un approccio multilivello:

• Validazione dei nomi dei pacchetti. Implementare controlli automatizzati che confrontino i nomi suggeriti dall’IA con registri ufficiali (PyPI, npm, Maven Central, ecc.) prima dell’installazione.
• Policy di approvazione manuale. Richiedere una revisione umana per ogni dipendenza suggerita da un assistente IA, soprattutto quando il nome non è già presente nel repository interno.
• SBOM esteso. Generare e mantenere un Bill of Materials del software (SBOM) che includa anche le dipendenze suggerite dall’IA, facilitando il tracciamento di eventuali pacchetti sospetti.
• Whitelist di fonti affidabili. Limitare le installazioni a registri certificati e firmati digitalmente, bloccando pacchetti provenienti da fonti non verificate.
• Monitoraggio dei registri di pacchetti. Utilizzare servizi di monitoraggio che avvisino in caso di nuove registrazioni di nomi simili a quelli suggeriti dall’IA.
• Formazione continua. Educare sviluppatori e team DevSecOps sui pericoli del slopsquatting e sulle pratiche di verifica dei pacchetti.
• Hardening dei modelli IA. Addestrare i modelli di generazione di codice a riconoscere e segnalare quando propongono nomi di pacchetti non presenti nei registri ufficiali.

Implementazione pratica di una whitelist

Una whitelist efficace può essere costruita così:

• Raccogliere l’elenco dei repository aziendali approvati (es. PyPI interno, Artifactory, Nexus).
• Configurare i gestori di pacchetti (pip, npm, cargo) per rifiutare pacchetti non presenti nella whitelist.
• Integrare il controllo nella pipeline CI/CD, in modo che ogni installazione venga verificata prima del build.
• Aggiornare periodicamente la whitelist con nuove versioni verificate, mantenendo un registro di audit.

Prospettive future

Con l’espansione dell’IA generativa, il fenomeno dello slopsquatting è destinato a crescere. Gli attacchi saranno sempre più sofisticati, con modelli che apprendono dai pattern di registrazione e cercano di evadere i controlli basati su firme statiche.

Le organizzazioni dovranno quindi evolvere le proprie strategie di difesa, passando da approcci reattivi a sistemi proattivi basati su intelligenza artificiale stessa, capaci di rilevare anomalie nei nomi dei pacchetti in tempo reale.

Nel frattempo, la collaborazione tra fornitori di tool IA, gestori di pacchetti e comunità open‑source sarà cruciale per definire standard condivisi, come “certificati di plausibilità” per i nomi di dipendenze suggeriti.

In sintesi, lo slopsquatting rappresenta una nuova frontiera della sicurezza della catena di fornitura del software, dove l’innovazione dell’IA si scontra con la necessità di controlli rigorosi. Solo un approccio combinato di policy, automazione, formazione e cooperazione settoriale potrà contenere questa minaccia emergente.