Il codice scritto dall’AI ha cambiato ciò che SAST deve rilevare

Guardare un assistente di codifica AI produrre una funzionalità lavorativa in pochi secondi può sembrare una svolta. Il codice compila. I test passano. La richiesta di pull sembra pulita. Per i team di sviluppo sotto pressione per spedire più velocemente, questo sembra un progresso.

Ma il codice funzionale e il codice sicuro non sono la stessa cosa.

Il codice generato dall’AI ha cambiato la forma del rischio software. Il problema non è semplicemente che i grandi modelli linguistici scrivono “cattivo” codice. In molti casi, scrivono codice che sembra lucido, segue un pattern di framework familiare e risolve il compito richiesto. Il problema è più sottile: il codice può essere funzionalmente corretto e ancora essere insicuro, superato, sovraautorizzato o contestualmente sbagliato.

Questa distinzione è importante perché la verifica di sicurezza dell’applicazione statica, o SAST, è stata costruita per un mondo in cui gli sviluppatori scrivevano codice alla velocità umana e i team di sicurezza esaminavano pattern di rischio prevedibili. L’AI ha cambiato entrambi i lati di quell’equazione. Il volume del codice sta aumentando, i commit stanno diventando più piccoli e gli schemi insicuri possono ora essere generati su larga scala.

Il risultato è una nuova domanda per i team software: cosa dovrebbe rilevare SAST quando l’autore del codice non è necessariamente umano?

Il codice funzionale non è più un segnale forte

Per anni, i team software hanno utilizzato una gerarchia di fiducia approssimativa. Se il codice compilava, superava i test e sopravviveva alla revisione paritaria, si avvicinava alla produzione. La scansione di sicurezza aggiungeva un altro livello, ma la funzionalità rimaneva il primo cancello.

Gli assistenti di codifica AI disturbano questa gerarchia perché sono particolarmente bravi a produrre codice che sembra completo. Possono inferire il codice boilerplate, connettere le API, generare la gestione degli errori e corrispondere allo stile di un repository esistente. Ciò li rende utili, ma rende anche più difficile rilevare i loro errori.

Un revisore umano può scorrere una funzione scritta dall’AI e pensare: “Questo sembra normale.” Questo è proprio il rischio. Molti vulnerabilità generate dall’AI non sono esotiche. Sono problemi familiari come difetti di iniezione, convalida debole, impostazioni di default insicure, deserializzazione insicura, problemi di registrazione e scelte di dipendenza superate.

La ricerca recente ha reso questa tensione più difficile da ignorare. Ad esempio, l’aggiornamento sulla sicurezza del codice GenAI di Veracode Spring 2026 ha scoperto che i modelli di codifica AI erano diventati molto più forti nella produzione di codice sintatticamente corretto che di codice sicuro. In altre parole, l’AI sta diventando molto brava a scrivere software che funziona, ma ciò non significa che stia diventando altrettanto brava a scrivere software che può essere fidato.

L’output può sembrare pronto per la produzione, ma il rischio sottostante può essere completamente diverso.

Il vecchio modello SAST è stato costruito per i collo di bottiglia umani

Il SAST tradizionale ha sempre avuto un compito difficile. Scansiona il codice sorgente, mappa i pattern alle debolezze note e avvisa i team prima che il codice vulnerabile venga spedito. In un ciclo di sviluppo convenzionale, ciò crea già attrito: troppi avvisi, troppi falsi positivi e non abbastanza tempo per risolvere tutto.

L’AI rende le cose più difficili rimuovendo una delle restrizioni nascoste nello sviluppo software: la velocità di digitazione umana.

Quando un assistente AI può generare un servizio, un file di test, un’integrazione API e uno snippet di configurazione in una sola sessione, la revisione di sicurezza non può fare affidamento sulle stesse ipotesi. Il rischio non è una sola riga di codice trascurata. È la moltiplicazione di codice plausibile in decine di file, ognuno con piccole decisioni che il modello ha preso per conto del team.

Questo è dove gli strumenti SAST moderni devono evolversi. Non possono semplicemente scansionare le firme di vulnerabilità note dopo che la richiesta di pull è quasi completa. Devono operare più vicino al flusso di lavoro dello sviluppatore, capire i pattern di modifica assistiti dall’AI e aiutare i team a separare l’automazione innocua dall’automazione rischiosa.

L’AI introduce il debito di sicurezza alla velocità della macchina

Il debito tecnico non è nuovo. Il debito di sicurezza è il cugino più pericoloso: si accumula quando le vulnerabilità, le ipotesi deboli e le scorciatoie rischiose rimangono nel codice base perché non sono abbastanza urgenti da risolvere oggi.

L’AI può accelerare questo processo.

<p Uno sviluppatore potrebbe chiedere a un assistente di "aggiungere l'autenticazione", "sanitizzare questo input" o "connettere questo endpoint al database". Il modello produrrà usualmente una risposta. Ma a meno che il prompt non includa le giuste restrizioni di sicurezza, la risposta potrebbe fare affidamento su pratiche superate, convalida incompleta o impostazioni di default insicure. Peggio, potrebbe essere abbastanza buona da superare una revisione casuale.

Ci sono diversi pattern specifici dell’AI che SAST deve ora riconoscere:

• Boilerplate sicuro: l’AI spesso produce codice che assomiglia alle migliori pratiche, ma manca di un importante controllo, come ad esempio controlli di autorizzazione o codifica di output.
• Ipotesi di dipendenza superate: un modello potrebbe suggerire librerie, versioni o API basate su pattern che erano comuni nei suoi dati di training, ma non sono più consigliati.
• Riparazioni senza contesto: l’AI può correggere il sintomo locale senza capire il flusso dell’applicazione più ampia, creando lacune di sicurezza altrove.
• Modelli vulnerabili ripetuti: se lo stesso prompt produce lo stesso pattern difettoso in più repository, una debolezza può diffondersi silenziosamente attraverso un’organizzazione.

Ciò non riguarda solo il trovare codice cattivo. Si tratta di rilevare quando il codice è stato prodotto senza abbastanza contesto.

SAST deve capire l’intento, non solo la sintassi

La prossima generazione di SAST dovrà andare oltre il semplice riconoscimento di pattern. I pattern di vulnerabilità note sono ancora importanti e molte lacune di base dovrebbero essere rilevate automaticamente. Ma il codice scritto dall’AI alza la barra perché la sintassi da sola raramente racconta tutta la storia.

Considera un endpoint che recupera i record dei clienti. Il codice potrebbe utilizzare query parametrizzate, gestire gli errori correttamente e superare i controlli di iniezione standard. Ma impone l’isolamento del tenant? Verifica se l’utente attuale è autorizzato ad accedere al record richiesto? Registra dati sensibili?

Questo tipo di modifica solleva anche una questione di privacy: se la logica generata dall’AI altera ciò che l’applicazione archivia, registra o espone, i team devono capire il suo comportamento di raccolta dei dati dell’app come parte della revisione di sicurezza.

Queste non sono sempre problemi di sintassi. Sono problemi di intento.

SAST necessita di maggiore consapevolezza della logica aziendale, del flusso di dati, delle convenzioni del framework e della relazione tra una modifica e il resto dell’applicazione. L’obiettivo non è quello di rendere SAST “potenziato dall’AI” per scopi di marketing. L’obiettivo è quello di renderlo abbastanza consapevole del contesto per rilevare il tipo di errori che l’AI è probabile commetta.

Gli sviluppatori devono ancora imparare la sicurezza, solo in modo diverso

Gli strumenti migliori aiuteranno, ma non rimuoveranno la responsabilità umana. Gli assistenti di codifica AI rendono gli sviluppatori più produttivi, ma rendono anche più facile per i team accettare codice che non capiscono completamente.

Ciò crea una sfida di formazione. La formazione di sicurezza annuale tradizionale è troppo lenta e troppo distaccata dal lavoro quotidiano. Gli sviluppatori necessitano di lezioni brevi e pratiche consegnate vicino al momento in cui stanno prendendo decisioni. È qui che l’apprendimento micro diventa rilevante: piccoli momenti di apprendimento possono rafforzare abitudini di codifica sicure senza rimuovere gli ingegneri dal loro flusso di lavoro per ore.

La migliore formazione di sicurezza nell’era della codifica AI assomiglierà meno a una classe e più a una spiegazione ben tempestiva all’interno di una richiesta di pull, un avviso IDE che insegna piuttosto che fastidisce, o una breve nota di risoluzione che spiega perché un pattern generato dall’AI è rischioso.

Il processo di revisione deve cambiare

La revisione del codice usava per rispondere a domande familiari: è il codice leggibile? Risolve il problema? Rompe qualcosa?

Il codice scritto dall’AI aggiunge nuove domande. Il prompt era consapevole della sicurezza? Il modello ha introdotto una dipendenza? Ha copiato un pattern da altrove nel repository senza capire perché quel pattern esisteva? Lo sviluppatore ha verificato la logica o solo l’output?

Ciò non significa che ogni commit assistito dall’AI necessiti di un’indagine forense. Ma i team necessitano di un modo leggero per identificare le modifiche generate dall’AI ad alto rischio. L’autenticazione, l’autorizzazione, la crittografia, i flussi di pagamento, i caricamenti di file, l’accesso al database, la registrazione e la configurazione dell’infrastruttura meritano più attenzione rispetto alla copia dell’interfaccia utente o al test scaffolding.

Il punto fondamentale

L’AI non sta rendendo SAST irrilevante. Sta rendendo SAST più importante.

Man mano che la generazione di codice diventa più veloce e più profondamente integrata negli ambienti di sviluppo, l’antica ipotesi che il codice insicuro entri lentamente attraverso le mani umane non è più valida. L’AI può generare software utile, ma può anche scalare pattern deboli, ipotesi superate e correzioni senza contesto più velocemente di quanto i processi di revisione tradizionali possano assorbire.

I vincitori non saranno i team che bandiscono gli strumenti di codifica AI. I vincitori saranno i team che ridisegnano i loro flussi di lavoro di sicurezza intorno alla nuova realtà: il codice può essere generato istantaneamente, ma la fiducia deve ancora essere guadagnata.

SAST deve ora rilevare più che gli errori di livello di sintassi. Deve rilevare l’intento mancante, il contesto insicuro, i pattern ripetuti dell’AI e il debito di sicurezza prima che si accumuli.