L'AI generativa per la sicurezza del codice software

AI generativa e Large Language Model hanno suscitato un grande interesse negli sviluppatori. Piace a tutti l'idea di poter velocizzare la scrittura di codice delegandone una parte, magari la più semplice, a uno dei vari "copiloti" che tutte le piattaforme di sviluppo stanno integrando. Gli sviluppatori sanno bene che il codice generato da AI al momento potrebbe non essere ottimale, ma le potenzialità degli LLM sono troppo interessanti per essere trascurate.

Il problema esiste. Bastano pochi suggerimenti sbagliati da parte di un motore di AI generativa integrato in qualche strumento di sviluppo per fare spiacevoli brutte figure. E la fretta iniziale del mercato non ha aiutato, mediaticamente. Per questo la crescita nell'adozione dei LLM "da sviluppatori" oggi è ancora veloce ma anche - nei limiti del possibile e del finanziariamente conveniente - più prudente.

C'è un problema in più da affrontare: la vulnerabilità della supply chain del software. Affidare a un motore di Intelligenza Artificiale la scrittura del codice applicativo può portare nuovi rischi, se il codice generato non è impeccabile dal punto di vista della cybersecurity. D'altro canto, gli LLM possono aiutare nella verifica della correttezza del codice, e questo è molto importante.

A livello teorico, c'è poi il rischio che gli stessi Large Language Model usati per i "copiloti" dello sviluppo vengano in qualche modo violati e portati a creare codice errato o persino malevolo. Ma questa è una ipotesi più complessa che va oltre lo stato attuale delle piattaforme di sviluppo per come lo vedono i loro utenti finali. Che sono anche, ricordiamolo, moltissime grandi imprese e non solo i singoi sviluppatori.

In generale, gli LLM - nelle intenzioni - dovrebbero aiutare a concretizzare un approccio di security by design spesso definito di "embedded security". In pratica, l'idea - corretta, peraltro - che il codice debba essere reso sicuro già nella fase di sviluppo e non solo in un ciclo di test, individuazione delle vulnerabilità e loro correzione ex post. Ciclo che va comunque seguito, ma che un approccio di codice sicuro by design semplificherebbe notevolmente.

Code scanning e secrets detection

Per capire come stanno andando le cose nel rapporto tra AI generativa, sviluppo software e cybsercurity è interessante vedere cosa stanno facendo le principali piattaforme per la gestione dello sviluppo e della parte di CI/CD. Tutte attività ormai intensamente collaborative in cui codice, librerie e informazioni di contorno sono quasi sempre in cloud. Con i vantaggi e i rischi del caso.

Dopo il boom di ChatGPT, tutto il mondo dello sviluppo sta integrando sempre più funzioni basate su LLM. Anche per la cybersecurity. In questa evoluzione il punto ideale di partenza sono le funzioni di sicurezza basate su LLM che in effetti molte piattaforme già avevano, grazie a motori di analisi statica del codice. Servivano, e servono ancora, per verificare che il codice non sia nativamente vulnerabile agli attacchi più comuni, come le SQL injection.

Ora queste funzioni di code scanning stanno facendo un logico passo in più con una parte di "autocorreazione": non basta evidenziare gli errori o le potenziali vulnerabilità che l'analisi statica ha trovato, è utile anche potere spiegarle in dettaglio (è il bello degli LLM, in fondo) e indicare le correzioni da apportare, dando inoltre la possibilità di apportarle automaticamente.

Un altro ambito in cui gli LLM permettono di avere una migliore cybersecurity è quella della cosiddetta "secrets detection". Le piattaforme di sviluppo collaborativo sono usate dagli sviluppatori per conservare e condividere molte informazioni legate allo sviluppo, non solo il codice in sé. Per questo capita spesso che sulle piattaforme siano caricati anche dati che sarebbe meglio non esporre, in particolare i "segreti" (password, nomi utente, chiavi di accesso...) che tutti gli hacker ostili cercano costantemente.

Così la cronaca della cybersecurity è ricca di casi in cui qualche "secrets leak" mette a rischio più o meno gravemente la sicurezza di infrastrutture, servizi e applicazioni. Per evitarlo bisogna scandagliare i repository online alla ricerca dei segreti - la secrets detection, appunto - che non dovrebbero esserci. Ma è una operazione improba da fare a mano e difficile da fare con strumenti automatici, perché si tratta di dati che non hanno una struttura identificabile a priori.

Gli LLM in questo ambito possono aiutare perché eseguono una ricerca di segreti che non si basa su pattern predefiniti ma sulla "esperienza" di un addestramento eseguito su una enorme mole di casi anonimizzati. Non è nemmeno questo un approccio dal successo garantito, ma dovrebbe portare a un numero inferiore di falsi positivi. Molte piattaforme di sviluppo e vendor di strumenti ad hoc si stanno muovendo in questo senso.

Unit test e sviluppo da zero

C'è molto interesse per l'utilizzo dell'AI generativa nell'unit testing. È quell'attività che tutti gli sviluppatori sanno di dover fare e che molti trascurano, banalmente perché richiede tempo e questo non è mai abbastanza. Un motore di AI generativa addestrato su uno specifico linguaggio o framework può scrivere gli unit test in automatico, lasciando allo sviluppatore solo il compito di eseguirli.

L'idea è talmente apprezzata che online abbondano i blog post di sviluppatori che hanno usato direttamente ChatGPT per creare unit test mirati. Con risultati quantomeno interessanti, ovviamente da non prendere come oro colato. I vendor tecnologici sono un po' più prudenti e considerano gli unit test generati da LLM in maniera più conservativa, valutando comunque interessante la loro efficacia nel testare effettivamente tutto il codice sottoposto. Tecnicamente, in termini di statement e branch coverage.

Infine, c'è una crescente componente di analytics applicata alla messa in sicurezza del codice. Questa parte di analisi, che è tipica dell'AI e del machine learning in generale, non riguarda strettamente gli LLM applicati al codice ma più in generale la valutazione delle politiche di miglioramento costante nella sicurezza dello sviluppo. Qui gli algoritmi di AI sono usati per valutare in dettaglio i risultati delle policy e delle procedure di sicurezza, a partire dalle informazioni raccolte ed elaborate da componenti come quelli descritti prima, in cui gli LLM giocano un ruolo chiave. L'idea è, ovviamente, migliorare nel tempo gli indicatori chave di solidità del codice.

Il passo successivo? È ancora un po' presto, ma chi è più avanti nella integrazione dell'AI generativa punta ad abilitare una sinergia ideazione-sviluppo-sicurezza sin dalle primissime fasi di concezione di un'applicazione o di un servizio. Ancora prima, cioè, di generare una singola linea di codice. Si parte da una idea generica, o da uno specifico problema da risolvere, e si lascia che sia un LLM a guidare lo sviluppo in maniera anche da generare codice affidabile.

Un esempio di questo approccio, anche se solo in fase preliminare, sono i Copilot Workspace della parte sperimentale di GitHub, GitHub Next. Sono ben descritti da una doppia metafora: se di norma i "copiloti" nello sviluppo sono un secondo paio di mani che aiuta nelle operazioni manuali, Copilot Workspace è "un secondo cervello" (parole di GitHub) per affrontare da zero problemi complessi. Lo sviluppo sicuro, magari con un linguaggio o un framework di cui non si è proprio esperti, è certamente tra questi problemi.