Immagine copertina generata con l’intelligenza artificiale
Gli strumenti di coding basati sull’intelligenza artificiale stanno aumentando rapidamente la velocità con cui nuovo software e nuove dipendenze entrano nelle pipeline aziendali. La produttività cresce, ma con essa anche una questione sempre più difficile da ignorare: chi verifica realmente il codice e i pacchetti suggeriti dall’AI? Secondo l’analisi riportata da ActiveState, il problema non riguarda soltanto gli sviluppatori, ma l’intera sicurezza della software supply chain.
La velocità dell’intelligenza artificiale nel coding
Gli assistenti AI sono ormai capaci di suggerire automaticamente librerie e dipendenze in pochi millisecondi. Il problema è che questo processo può procedere a una velocità superiore rispetto ai tradizionali controlli di sicurezza.
Le analisi SCA, Software Composition Analysis, vengono spesso eseguite dopo che il codice è stato scritto o inserito in una pull request. Quando però le dipendenze vengono generate a ritmo macchina, i controlli successivi rischiano di trasformarsi in un accumulo di segnalazioni difficili da gestire.
Un problema di scala nella revisione del codice open source
La questione coinvolge anche l’ecosistema open source. Gli assistenti AI non vengono utilizzati soltanto nelle aziende, ma producono anche contributi e pull request destinati a progetti gestiti dalla comunità.
Secondo una ricerca di CodeRabbit citata nella fonte, un’analisi di 470 pull request open source ha rilevato una densità di difetti superiore del 70% nei contributi realizzati con il supporto dell’AI rispetto a quelli prodotti esclusivamente da esseri umani. Anche i principali progetti open source stanno adottando politiche differenti sull’utilizzo dell’intelligenza artificiale.
Governa i pacchetti open source alla selezione
Il punto centrale della strategia proposta è spostare i controlli prima dell’ingresso della dipendenza nell’ambiente di sviluppo. Invece di attendere che una libreria venga utilizzata e successivamente analizzata, l’obiettivo è stabilire in anticipo quali componenti possono essere introdotti.
Un catalogo curato di pacchetti consente di verificare la provenienza del software e di limitare l’accesso diretto a repository pubblici non controllati, senza obbligare gli sviluppatori a rinunciare agli assistenti AI.
I rischi delle dipendenze AI non verificate
Uno dei pericoli più specifici è lo slopsquatting, ovvero lo sfruttamento delle allucinazioni dei modelli AI nella generazione dei nomi dei pacchetti. Gli LLM formulano suggerimenti sulla base di probabilità e modelli ricavati dal codice esistente, senza verificare necessariamente in tempo reale che un determinato pacchetto esista.
Se il nome suggerito non è presente su PyPI o npm, un attaccante può registrarlo, inserire al suo interno codice malevolo e attendere che qualche ambiente automatizzato lo scarichi.
Strategie operative nella scelta delle dipendenze AI
La fonte indica tre direttrici principali. La prima consiste nel limitare l’accesso diretto ai repository pubblici da parte di workstation e agenti AI. La seconda prevede di isolare le nuove dipendenze in ambienti controllati, così da analizzarne vulnerabilità e raggiungibilità prima dell’integrazione.
La terza riguarda la creazione di un vero e proprio gateway di ingestione, capace di verificare e curare preventivamente i pacchetti destinati agli sviluppatori, alle pipeline CI/CD e agli agenti artificiali.
Cosa fare adesso
Bloccare gli strumenti AI non appare una soluzione praticabile, considerati i vantaggi in termini di produttività. La priorità diventa quindi modificare le regole con cui il software viene introdotto negli ambienti aziendali.
I dati citati da Kusari mostrano il divario: l’85% delle organizzazioni utilizza assistenti AI per il coding, mentre soltanto il 9% dispone di controlli AppSec specifici per l’intelligenza artificiale. La sicurezza dovrà quindi intervenire sempre più vicino al momento della selezione della dipendenza, prima che questa possa raggiungere una build.
Fonte: BleepingComputer
