TLDR

  • HalluSquatting è il rischio in cui un modello suggerisce un pacchetto che non esiste, ma dal nome plausibile.
  • Un attaccante può registrare quel nome su un registry pubblico e aspettare che qualcuno copi l'installazione proposta dall'AI.
  • Il problema non è solo l'allucinazione: è 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.

Perché conta ora

La supply chain open source era già 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 lì: nel momento esatto in cui l'AI suggerisce una libreria che non esiste.

Non è fantascienza elegante. È un problema pratico. Se abbastanza modelli ripetono un nome plausibile, un attaccante può 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 più, un trattino spostato. HalluSquatting punta su una cosa più sottile: la fiducia nel suggerimento autorevole.

Il pacchetto non sembra falso perché lo hai digitato male. Sembra vero perché l'assistente lo ha nominato con naturalezza.

Il punto debole non è il modello, è 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 più correggendo un consiglio sbagliato. Stai valutando una piccola pipeline automatica.

Il rischio aumenta quando:

  • l'agente può 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 perché "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 può 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 dà 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 lì può 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 già 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:

  1. Il pacchetto esisteva già prima del suggerimento?
  2. Ha un repository coerente, issue reali e maintainer riconoscibili?
  3. La data di pubblicazione è sospetta rispetto alla discussione che lo cita?
  4. Il nome è simile a una libreria nota?
  5. Il package contiene script di installazione o build strani?
  6. Il lockfile introduce transitive dependency inattese?
  7. Il pacchetto serve davvero o basta codice locale più piccolo?
  8. In CI viene installato da registry pubblico o mirror controllato?

La domanda fondamentale è 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 è una dipendenza. È 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 è che i modelli sbagliano. Lo sappiamo.

La parte interessante è 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 è.

Una dipendenza non è una riga di codice. È una relazione di fiducia con sconosciuti, registry, toolchain, maintainer e transitive dependency.

HalluSquatting ci ricorda una cosa molto Able2Code: la comodità non cancella l'attacco, lo rende più elegante.

L'agente può scrivere codice.

La fiducia, invece, devi ancora compilarla tu.

FAQ

Che cos’è HalluSquatting?

È 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 può installare codice malevolo.

HalluSquatting è 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?

Sì, se possono modificare dipendenze, lanciare installazioni o accettare automaticamente fix. La catena diventa più 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 autorità sulla supply chain. Ogni nuova dipendenza deve passare da verifica tecnica e policy.

Fonti