Gli strumenti di coding AI velocizzano lo sviluppo ma introducono rischi legati a dipendenze non verificate, creando nuove sfide di sicurezza nell'ingestione open source e nella gestione della supply chain.
Durante la recente edizione di Black Hat, il tema dominante tra responsabili AppSec, ingegneri di piattaforma e CISO è stato uno: chi verifica davvero il codice generato dall'AI? L'adozione di strumenti di coding AI continua a crescere grazie ai vantaggi in termini di produttività, mentre il software open source resta la base delle applicazioni aziendali moderne. Tuttavia, la velocità con cui gli assistenti AI suggeriscono dipendenze di terze parti ha superato di gran lunga i processi tradizionali di revisione dell'ingestione, creando un nuovo fronte di rischio per la sicurezza.
Quando una dipendenza non verificata o "allucinata" entra nel codice a velocità macchina, le scansioni SCA post-commit faticano a stare al passo. Garantire la sicurezza non significa rallentare gli sviluppatori o limitare l'open source, ma governare ciò che entra nell'ambiente già al momento della selezione, prima ancora che un import attivi la build.
Slopsquatting e ingestione automatica: come nasce la vulnerabilità
I modelli linguistici di grandi dimensioni (LLM) suggeriscono librerie software basandosi su probabilità statistiche e pattern storici, senza verificare in tempo reale i registri dei pacchetti. Se il modello propone un nome di pacchetto inesistente su PyPI o npm, si apre una vulnerabilità nota come slopsquatting (o sfruttamento delle allucinazioni AI sui pacchetti).
Uno studio USENIX Security su sedici modelli di code generation e oltre 500.000 campioni ha evidenziato che una quota significativa dei nomi suggeriti non esiste nei registri pubblici. Tra quelli che esistono, quasi la metà contiene CVE noti o versioni obsolete.
Gli attaccanti monitorano i pattern di output degli LLM e i repository degli sviluppatori per individuare questi nomi "allucinati". Una volta identificato, registrano il nome su PyPI o npm, caricano un payload malevolo e attendono che ambienti automatizzati o pipeline CI/CD lo scarichino.
Nel 2026, i ricercatori hanno tracciato la diffusione di un pacchetto npm inesistente (react-codeshift) generato da 47 agenti AI in un solo commit, propagatosi poi in oltre 230 repository tramite fork, senza che nessun umano lo avesse mai selezionato consapevolmente. Il problema non era la malizia dello sviluppatore, ma l'assenza totale di controlli sull'ingestione.
Bloccare le allucinazioni AI prima della build
Gli assistenti AI generano codice a velocità macchina, ma le dipendenze non verificate espongono la pipeline a slopsquatting e attacchi supply chain. Soluzioni come ActiveState, basate su repository sicuri di componenti open source verificati e costruiti dal sorgente, permettono di attestare la provenienza del software e bloccare i vettori di slopsquatting già in fase di intake.
Questa sfida di intake non riguarda solo le aziende: gli stessi assistenti AI generano pull request automatiche verso repository open source mantenuti dalla community, aumentando la pressione sui maintainer umani. Progetti come Kubernetes, Linux kernel, LLVM e Godot hanno adottato policy divergenti: alcuni vietano il codice AI, altri lo accettano solo con responsabilità umana esplicita. Un'analisi CodeRabbit su 470 PR open source ha rilevato che i contributi co-autoriati da AI presentano il 70% di difetti in più rispetto a quelli scritti da umani, pur risultando apparentemente "puliti".
Quando pacchetti allucinati o vulnerabili passano l'ingestione aziendale, finiscono spesso anche nelle PR upstream, costringendo i maintainer volontari a ore di verifica su dipendenze mai valutate da un umano.
Governance: velocità contro verifica
Secondo il report Application Security in Practice di Kusari, l'adozione degli strumenti supera di gran lunga i controlli di intake:
- 85% delle organizzazioni usa assistenti AI per il coding
- 38% li impiega per la revisione delle PR
- Solo il 9% dispone di controlli AppSec dedicati all'AI
I workflow AppSec tradizionali si basano su scansioni post-scrittura o post-PR. Ma con codice generato a velocità macchina, gli alert tardivi diventano solo rumore ignorato dagli ingegneri.
Proteggere la pipeline già al momento della selezione
Non si può attendere che il tasso di allucinazione degli LLM scenda a zero: il vero problema è la velocità, non la precisione del modello. Per proteggere la pipeline senza sacrificare la produttività, le aziende stanno spostando la difesa a monte dell'IDE:
- Bloccare il fetch diretto dai registry pubblici non verificati durante l'autocompletamento AI.
- Isolare le nuove dipendenze suggerite dall'AI in sandbox per analisi automatica prima dell'inserimento nei branch principali.
- Governare il gateway di ingestione, passando da una logica reattiva sui CVE a una curazione proattiva delle fonti, verificando ogni pacchetto suggerito dall'AI contro typosquat e slopsquatting.
Questa logica di intake è il cuore della Secure Open Source Library e del Catalogo Curato di ActiveState, che agisce come gateway aziendale tra registry pubblici e strumenti degli sviluppatori, fornendo solo pacchetti open source pre-verificati e continuamente aggiornati. Così, i rischi legati ai pacchetti allucinati vengono intercettati prima della selezione, riducendo l'esposizione ai CVE fino al 95% senza dover rinunciare agli assistenti AI.
Il tema della sicurezza della supply chain software è sempre più centrale, come dimostrato anche da recenti attacchi supply-chain che hanno colpito plugin WordPress, dove la compromissione upstream ha permesso la creazione di account amministratore non autorizzati: un esempio è descritto nell'analisi su come le vulnerabilità nella catena di fornitura possono essere sfruttate per attacchi mirati.
Conclusione
Disabilitare gli strumenti di coding AI non è una soluzione praticabile né competitiva. Ma integrare l'AI solo come leva di produttività, senza aggiornare le regole di ingestione della supply chain, espone i build di produzione a compromissioni automatizzate. La sicurezza della pipeline moderna richiede che ogni pacchetto selezionato da sviluppatori o agenti sia governato di default prima di arrivare alla build.
