Copilot, Cursor, Claude, ChatGPT.
Gli strumenti di intelligenza artificiale per la scrittura di codice sono entrati nei flussi di lavoro di milioni di sviluppatori. Consentono di creare funzionalità in pochi minuti, ridurre il lavoro ripetitivo e accelerare lo sviluppo del software.
I vantaggi sono reali e difficilmente reversibili.
Ma c'è una domanda che molte organizzazioni non si stanno ancora ponendo con la dovuta attenzione:
chi controlla che il codice generato dall'AI sia davvero sicuro?
La questione non riguarda la qualità del codice o la produttività degli sviluppatori. Riguarda il rischio.
Perché un'applicazione può funzionare perfettamente, superare tutti i test funzionali e contenere comunque vulnerabilità in grado di esporre dati, interrompere servizi o facilitare un attacco informatico.
L'intelligenza artificiale sta abbassando il costo di produzione del software. La vera sfida è evitare che abbassi anche il costo di introduzione delle vulnerabilità.
Come viene generato il codice dall'AI
Gli assistenti di coding basati su modelli linguistici non scrivono software come farebbe uno sviluppatore esperto che conosce l'azienda, i requisiti di sicurezza e il contesto operativo.
Generano codice sulla base di pattern statistici appresi da enormi quantità di codice disponibile pubblicamente.
Questo significa che possono produrre soluzioni corrette dal punto di vista sintattico, che compilano e che funzionano.
Ma funzionare non significa necessariamente essere sicuri.
I dati utilizzati per addestrare questi modelli contengono sia buone pratiche sia implementazioni vulnerabili, configurazioni errate, utilizzi impropri della crittografia e codice scritto senza particolari attenzioni alla sicurezza.
L'AI non comprende realmente il rischio associato a una determinata scelta progettuale. Produce semplicemente la soluzione che, statisticamente, appare più probabile.
C'è poi un altro aspetto spesso sottovalutato.
L'assistente AI non conosce la tua organizzazione.
Non conosce le policy sulla gestione dei log, la classificazione dei dati, i requisiti normativi, il modello di minaccia o il livello di rischio accettabile.
Una soluzione apparentemente corretta potrebbe essere completamente inadatta al contesto in cui verrà utilizzata.
Un esempio concreto
Immaginiamo di chiedere a un assistente AI di generare una funzione per il login di un'applicazione.
Nel giro di pochi secondi otteniamo il risultato.
Il codice compila.
Gli utenti riescono ad autenticarsi.
I test funzionali passano.
Tutto sembra perfetto.
Eppure quella stessa funzione potrebbe registrare nei log informazioni che non dovrebbero essere conservate, non applicare correttamente i controlli di autorizzazione oppure gestire in modo inadeguato gli errori.
Dal punto di vista dell'utente il sistema funziona.
Dal punto di vista della sicurezza, invece, la vulnerabilità è già presente.
Ed è proprio questo il rischio più insidioso del codice generato dall'AI: gli errori non sono sempre evidenti.
Le vulnerabilità più frequenti
Le analisi condotte negli ultimi anni hanno evidenziato alcuni pattern ricorrenti nel codice generato dagli assistenti AI.
Tra i più comuni troviamo:
- validazione insufficiente degli input che può facilitare attacchi di tipo injection;
- credenziali o segreti inseriti direttamente nel codice;
- utilizzo improprio di funzioni crittografiche;
- gestione non corretta degli errori e delle eccezioni;
- problemi legati ai controlli di autorizzazione;
- suggerimenti di librerie o dipendenze vulnerabili;
- errori logici che emergono quando più utenti o processi utilizzano contemporaneamente la stessa applicazione.
Uno studio dell'Università di Stanford ha evidenziato un aspetto particolarmente interessante: gli sviluppatori che utilizzavano assistenti AI tendevano a produrre codice con un numero maggiore di vulnerabilità rispetto al gruppo di controllo, pur dichiarandosi più sicuri della qualità del risultato.
Questo fenomeno è probabilmente uno dei rischi più importanti.
La fiducia percepita cresce più velocemente della sicurezza reale.
Il rischio che molti manager stanno sottovalutando
Molte aziende misurano il successo degli strumenti AI attraverso indicatori di produttività.
Più funzionalità sviluppate.
Più velocità.
Più codice prodotto.
È una valutazione comprensibile.
Ma esiste una domanda che dovrebbe interessare direttamente CISO, CIO e management:
la capacità di verificare quel codice sta crescendo alla stessa velocità con cui viene generato?
Se il volume di software prodotto aumenta del 50%, ma la capacità di revisione e verifica rimane invariata, il rischio non diminuisce.
Potrebbe addirittura aumentare.
L'adozione degli assistenti AI non è soltanto una questione tecnologica. È una questione di governance del rischio.
Chi sta facendo davvero la code review?
In molti team di sviluppo la revisione del codice è già sotto pressione.
I rilasci sono più frequenti.
Le aspettative di business sono più elevate.
La quantità di codice prodotto continua a crescere.
L'AI accelera ulteriormente questo processo.
Il rischio è che il codice generato automaticamente venga revisionato in modo superficiale perché appare già ordinato, leggibile e professionale.
Esiste un effetto psicologico ben noto: quando qualcosa appare ben fatto, tendiamo a fidarci più facilmente.
Ma la qualità estetica del codice non garantisce la sua sicurezza.
Una revisione efficace dovrebbe verificare almeno:
- validazione degli input;
- gestione delle autorizzazioni;
- protezione dei dati sensibili;
- logging e monitoraggio;
- gestione degli errori;
- utilizzo corretto della crittografia;
- dipendenze e librerie utilizzate.
In altre parole, l'AI può accelerare la scrittura del codice. Non elimina la necessità di una revisione rigorosa.
Anche il modello fa parte della supply chain
C'è poi un rischio meno evidente.
Quando si utilizza un assistente AI, il modello stesso entra a far parte della supply chain del software.
Alcuni studi hanno dimostrato che, almeno in teoria, è possibile influenzare il comportamento di un assistente di coding attraverso tecniche di manipolazione dei dati utilizzati per l'addestramento.
Non si tratta di un rischio diffuso oggi, ma è un promemoria importante.
La sicurezza non riguarda soltanto il codice generato.
Riguarda anche gli strumenti che contribuiscono a generarlo.
Il ruolo del CISO
Per i responsabili della sicurezza la domanda non dovrebbe essere:
"Possiamo vietare l'uso dell'AI?"
Nella maggior parte delle organizzazioni la risposta è già arrivata.
Gli sviluppatori utilizzano questi strumenti e continueranno a farlo.
La vera sfida consiste nel creare regole e controlli adeguati.
Framework come il NIST Secure Software Development Framework (SSDF) offrono una base solida per integrare la sicurezza nel ciclo di vita del software, indipendentemente da chi scrive il codice.
In pratica significa:
- definire una policy chiara sull'uso degli assistenti AI;
- vietare l'inserimento nei prompt di credenziali, chiavi e dati sensibili;
- identificare le aree di codice ad alto rischio che richiedono sempre revisione umana;
- integrare controlli automatici nelle pipeline di sviluppo;
- formare gli sviluppatori sui rischi specifici del codice generato dall'AI.
L'obiettivo non è bloccare l'innovazione.
È renderla governabile.
Analisi statica e AI: non sono concorrenti
Con l'aumento del codice generato automaticamente, strumenti come analizzatori statici, secret scanner e piattaforme di software composition analysis diventano ancora più importanti.
Soluzioni come Semgrep, SonarQube, Checkmarx o Snyk consentono di individuare vulnerabilità e configurazioni rischiose prima che il software venga distribuito.
Esistono inoltre ricerche promettenti che utilizzano gli stessi modelli linguistici per identificare vulnerabilità nel codice.
È una direzione interessante.
Ma almeno per ora, questi strumenti devono essere considerati un supporto aggiuntivo e non una sostituzione dei controlli tradizionali.
La responsabilità rimane umana
C'è un aspetto che non dovrebbe mai essere dimenticato.
Quando un'applicazione viene compromessa a causa di una vulnerabilità, nessuno chiederà se quel codice è stato scritto da uno sviluppatore o da un modello linguistico.
L'incidente riguarderà l'organizzazione che ha rilasciato il software.
L'AI non firma il codice.
Non partecipa agli audit.
Non compare nei report di incident response.
La responsabilità resta a chi sviluppa, approva e distribuisce il software.
Cosa possono fare le aziende oggi
Un punto di partenza concreto può essere:
- censire gli strumenti AI già utilizzati dai team di sviluppo;
- definire una policy aziendale sul loro utilizzo;
- identificare le aree di codice che richiedono sempre una revisione approfondita;
- rafforzare i controlli automatici nelle pipeline CI/CD;
- adottare framework come il NIST SSDF per strutturare il processo;
- formare sviluppatori e responsabili tecnici sui rischi specifici del codice AI-generato;
- monitorare nel tempo qualità e sicurezza del software prodotto.
La velocità non basta
L'intelligenza artificiale sta cambiando radicalmente il modo in cui il software viene sviluppato.
La domanda non è più se utilizzare questi strumenti.
La domanda è come governarli.
La velocità con cui oggi possiamo generare codice è aumentata enormemente.
La capacità di verificarlo deve crescere allo stesso ritmo.
Perché quando si parla di sicurezza, la responsabilità rimane sempre umana.