TLDR
- HalluSquatting e il rischio in cui un modello suggerisce un pacchetto che non esiste, ma dal nome plausibile.
- Un attaccante puo registrare quel nome su un registry pubblico e aspettare che qualcuno copi l'installazione proposta dall'AI.
- Il problema non e solo l'allucinazione: e il workflow automatico che installa, testa e committa senza verificare la provenienza.
- La difesa passa da lockfile, mirror controllati, allowlist, review delle dipendenze e sandbox per agenti di coding.
Perche conta ora
La supply chain open source era gia un labirinto prima degli agenti AI. Adesso nel labirinto abbiamo messo un assistente che parla con sicurezza, scrive patch, sistema errori, aggiunge dipendenze e a volte inventa nomi che sembrano perfetti.
HalluSquatting vive li: nel momento esatto in cui l'AI suggerisce una libreria che non esiste.
Non e fantascienza elegante. E un problema pratico. Se abbastanza modelli ripetono un nome plausibile, un attaccante puo registrarlo in un registry pubblico e aspettare che qualcuno lo installi. Il pacchetto nasce dopo l'allucinazione, ma arriva prima della verifica umana.
Il vecchio typosquatting puntava su una svista: reqeusts invece di requests, una lettera in piu, un trattino spostato. HalluSquatting punta su una cosa piu sottile: la fiducia nel suggerimento autorevole.
Il pacchetto non sembra falso perche lo hai digitato male. Sembra vero perche l'assistente lo ha nominato con naturalezza.
Il punto debole non e il modello, e il flusso
Se un chatbot suggerisce una libreria inesistente e tu la controlli, il danno si ferma presto.
Se un agente di coding modifica package.json, lancia l'installazione, aggiorna il lockfile, fa passare i test e ti mostra un diff pulito, il problema cambia scala. Non stai piu correggendo un consiglio sbagliato. Stai valutando una piccola pipeline automatica.
Il rischio aumenta quando:
- l'agente puo installare dipendenze senza conferma;
- i registry pubblici sono raggiungibili dall'ambiente di sviluppo;
- il progetto non usa mirror o allowlist aziendali;
- i test verificano solo che il codice funzioni, non da dove arriva;
- la review guarda il codice applicativo e ignora lockfile e metadata;
- le nuove dipendenze vengono accettate perche "le ha aggiunte l'assistente".
Il malware supply chain ama i punti ciechi. E i lockfile sono spesso uno di questi: troppo lunghi per essere letti, troppo importanti per essere ignorati.
Come funziona l'inganno
La catena puo essere molto semplice.
Un modello suggerisce un nome credibile per risolvere un problema tecnico: una libreria per parsing, sicurezza, logging, validazione o integrazione cloud. Il nome non esiste ancora, ma assomiglia allo stile del linguaggio e del registry.
Un attaccante registra quel pacchetto. Gli da una descrizione convincente, magari un repository finto, qualche commit, una README copiabile e una versione che non sembra troppo nuova. Poi aspetta.
Quando uno sviluppatore o un agente ripete quel suggerimento e installa la dipendenza, il codice entra nel progetto. Da li puo fare cose diverse: esfiltrare variabili d'ambiente, leggere token, alterare build, aggiungere post-install script o restare silenzioso fino alla CI.
Non servono istruzioni spettacolari. Basta infilarsi nel posto in cui il team ha gia deciso di fidarsi: il gestore pacchetti.
Cosa controllare prima di accettare una dipendenza
Una dipendenza nuova dovrebbe sempre far accendere una spia, anche quando arriva da un assistente AI.
Checklist veloce:
- Il pacchetto esisteva gia prima del suggerimento?
- Ha un repository coerente, issue reali e maintainer riconoscibili?
- La data di pubblicazione e sospetta rispetto alla discussione che lo cita?
- Il nome e simile a una libreria nota?
- Il package contiene script di installazione o build strani?
- Il lockfile introduce transitive dependency inattese?
- Il pacchetto serve davvero o basta codice locale piu piccolo?
- In CI viene installato da registry pubblico o mirror controllato?
La domanda fondamentale e brutale: "Se questo pacchetto fosse malevolo, cosa potrebbe leggere nel nostro ambiente?"
Se la risposta include token cloud, chiavi deploy, .env, registry privati o repo interni, non e una dipendenza. E una porta.
Difesa per team piccoli
Non serve un programma enterprise da mille slide.
Servono abitudini dure:
- niente installazioni automatiche da agenti AI su repository non fidati;
- approvazione umana per nuove dipendenze;
- lockfile trattato come codice sensibile;
- registry mirror per ambienti di build;
- secret scanning anche su CI e log;
- token con permessi minimi;
- ambienti sandbox per prove rapide;
- report periodico delle dipendenze aggiunte nell'ultima settimana.
Se usi agenti di coding, aggiungi una regola chiara: possono proporre una libreria, ma non possono decidere da soli che entra nel progetto.
Il dettaglio culturale
La parte interessante non e che i modelli sbagliano. Lo sappiamo.
La parte interessante e che stanno diventando abbastanza utili da farci abbassare la guardia. Quando un assistente scrive dieci fix corretti di fila, l'undicesimo suggerimento sembra appartenere alla stessa categoria. Non lo e.
Una dipendenza non e una riga di codice. E una relazione di fiducia con sconosciuti, registry, toolchain, maintainer e transitive dependency.
HalluSquatting ci ricorda una cosa molto Able2Code: la comodita non cancella l'attacco, lo rende piu elegante.
L'agente puo scrivere codice.
La fiducia, invece, devi ancora compilarla tu.
FAQ
Che cos'e HalluSquatting?
E una forma di rischio supply chain in cui un modello AI inventa nomi di librerie o pacchetti plausibili. Se un attaccante registra quei nomi, chi segue il suggerimento dell'AI puo installare codice malevolo.
HalluSquatting e uguale al typosquatting?
No. Nel typosquatting l'attaccante imita un nome reale con un errore di digitazione. Nell'HalluSquatting sfrutta un nome inesistente ma credibile, spesso generato o suggerito da un assistente AI.
Gli agenti di coding rendono il problema peggiore?
Si, se possono modificare dipendenze, lanciare installazioni o accettare automaticamente fix. La catena diventa piu rischiosa quando l'umano controlla solo il risultato finale.
Come si riduce il rischio di pacchetti fantasma?
Verifica manualmente il registry, usa lockfile, evita installazioni automatiche da suggerimenti AI, blocca pacchetti non approvati e controlla maintainer, download, repository e firma quando disponibili.
Serve vietare gli assistenti AI nello sviluppo?
No. Serve trattarli come generatori di ipotesi, non come autorita sulla supply chain. Ogni nuova dipendenza deve passare da verifica tecnica e policy.