La sicurezza dell’IA ha bisogno di un secondo parere

L’IA scrive software più velocemente di quanto riusciamo a proteggerlo. Riuscite a stare al passo?

Nel tempo che impiegherete a leggere questa frase, gli sviluppatori e i loro agenti IA avranno inviato un paio di migliaia di commit di codice. L’anno scorso, in questo stesso periodo, sarebbero stati circa 150.

Nell’ultimo anno, il software generato dall’IA ha accelerato a ritmi sbalorditivi. GitHub ha registrato 7,38 miliardi di commit nel solo settembre 2026, oltre cinque volte il totale di un anno prima. Le implicazioni di questa esplosione per la sicurezza sono profonde. Ognuno di quei commit contiene codice che qualcuno dovrebbe comprendere, mantenere e proteggere. Cloud Security Alliance ha rilevato che, nelle aziende Fortune 50, gli sviluppatori che usano l’IA inviano commit di codice a un ritmo da tre a quattro volte superiore a quello dei colleghi, mentre i loro rilievi mensili sulla sicurezza sono aumentati di circa dieci volte.

Ora pensiamo a chi deve fare i conti con questo aumento. Il team del CISO ha le stesse dimensioni di un anno fa, ma l’arretrato no. Le segnalazioni di vulnerabilità aumentano, le correzioni mensili diminuiscono e cresce il numero di criticità irrisolte. Non sorprende che Gartner affermi che il burnout dei CISO sta diventando un rischio operativo critico.

La tentazione di scegliere il modello più recente

Quando il numero è così alto, viene spontaneo puntare a un numero ancora maggiore: più rilievi, più copertura, più scansioni. Ma è come svuotare una barca che affonda e chiedere un secchio più grande, quando invece bisognerebbe trovare la falla. La qualità di un programma di sicurezza non si misura da quanto riesce a individuare. Si misura da quanti dei problemi individuati sono reali e da quanti dei più critici vengono effettivamente risolti.

I modelli di IA di frontiera sono straordinari nel trovare exploit inediti e vulnerabilità non catalogate grazie al ragionamento probabilistico. Tuttavia, i risultati variano. Secondo una ricerca di Checkmarx, eseguendo cinque volte la stessa scansione sullo stesso codice, i risultati coincidono solo in circa un terzo dei casi.

È proprio questa incoerenza a rendere ancora importante l’analisi basata su regole. È meno flessibile dell’IA di frontiera, ma applica ogni volta la stessa logica comprovata, così i team possono fidarsi dei risultati e verificarli. L’IA individua ciò che sfugge alle regole, per esempio vulnerabilità note che si presentano in forme insolite o difetti sfruttabili solo quando interagiscono parti diverse del codice. Insieme, l’IA e l’analisi basata su regole fanno emergere più problemi rilevanti, con meno falsi allarmi.

Niente di tutto questo è un argomento contro l’IA. È un argomento a favore della necessità di un secondo parere sulla sicurezza. Qualunque motore scegliate, sottoponetelo a tre domande.

Prima domanda: fedeltà

Quando lo scanner segnala un problema, vale la pena dedicarci del tempo?

La fedeltà significa affidabilità. Un rilievo non reale fa perdere un pomeriggio a uno sviluppatore e toglie un po’ di credibilità al team di sicurezza. Su larga scala, i falsi positivi fanno sì che i team smettano di ascoltare. Gli avvisi diventano un «al lupo, al lupo» e si confondono con il rumore di fondo.

È qui che la coerenza conta. L’analisi deterministica restituisce sempre la stessa risposta sullo stesso codice: questo crea fiducia e rende i risultati verificabili.

Seconda domanda: accuratezza

Riuscite a individuare tutti i problemi più importanti?

La fedeltà indica se un rilievo merita il vostro tempo, ma non dice che cosa è sfuggito allo scanner. Utilizziamo una misura pratica, nata nell’ambito della scienza dei dati, chiamata punteggio F1. Il punteggio F1 misura le prestazioni su una scala da 1 a 0, sulla base di due fattori:

• Precisione: la percentuale dei rilievi segnalati che sono reali. Un’elevata precisione significa meno falsi allarmi.
• Copertura: la percentuale delle vulnerabilità reali che lo scanner riesce effettivamente a individuare. Un’elevata copertura significa che pochi problemi sfuggono.

Uno scanner può sembrare preciso segnalando quasi nulla o scrupoloso segnalando tutto, ma in entrambi i casi il punteggio F1 può essere basso. La media del settore è di circa 0,20. Ci siamo impegnati molto per affrontare questa sfida e abbiamo ottenuto risultati con un’accuratezza da tre a quattro volte superiore a quella di uno scanner standard.

Una maggiore accuratezza semplifica ogni fase successiva per gli sviluppatori. Il team dedica meno tempo alla verifica e più tempo alla risoluzione dei problemi.

Terza domanda: ROI

Come possiamo massimizzare gli investimenti e le risorse?

È la domanda che più spesso viene tralasciata durante il progetto pilota e a cui è più doloroso rispondere una volta passati alla produzione.

I modelli di IA di frontiera fatturano in base ai token, che vengono consumati indipendentemente dal fatto che una scansione rilevi o meno qualcosa. Scansionare un repository con un milione di righe costa più di mille dollari ai prezzi attualmente pubblicati. Inoltre, il consumo di token varia notevolmente da un modello all’altro: il prezzo varia in base al modello scelto e alla quantità di ragionamento necessaria per portare a termine il lavoro.

Moltiplicate questa spesa per ogni commit, richiesta pull e repository di un’azienda. Uber, che spende 3,4 miliardi di dollari all’anno in R&D, secondo quanto riferito avrebbe esaurito l’intero budget per l’IA del 2026 nel giro di pochi mesi dal lancio degli strumenti di programmazione basati sull’IA.

La chiamiamo tassa sui token. È come usare una Ferrari per fare la spesa: paghi una potenza che il viaggio non richiede. Le credenziali codificate nel codice e le iniezioni SQL sono schemi prevedibili che l’analisi deterministica rileva in modo affidabile.

La sicurezza delle applicazioni deve evolversi

È questo il ragionamento alla base dell’architettura di Checkmarx Fusion. I motori basati su regole stabiliscono una verità di riferimento in modo riproducibile e a costi inferiori rispetto all’analisi basata sui token. I modelli di frontiera si concentrano su ciò che le regole non possono prevedere: schemi inediti, logiche complesse e sfruttabilità nel contesto. Infine, un livello di analisi dei risultati integra i dati in un unico insieme affidabile.

L’analisi deterministica offre certezza. L’IA offre maggiore portata. Copertura e affidabilità aumentano insieme. Rispetto a un LLM che opera da solo, osserviamo una fedeltà fino a quattro volte maggiore, una precisione da due a quattro volte superiore e costi pari a circa un terzo.

Individuare i problemi è solo l’inizio. Lo stesso principio vale per la prevenzione. Facciamo un esempio. Se mettiamo gli sviluppatori nelle condizioni di intervenire nel momento stesso in cui creano il codice, nell’IDE in cui lo scrivono, possiamo fermare i problemi prima che si presentino. Allo stesso modo, per le vulnerabilità che riescono comunque a passare, perché non fornire agli sviluppatori correzioni pronte per essere integrate, dando la priorità a quelle più importanti? Sono queste le sfide che stiamo affrontando, con l’obiettivo di ridurre gradualmente l’arretrato esistente e ottenere il massimo impatto nel minor tempo e con il minimo sforzo.

Il codice è già in esecuzione. Riesci a stare al passo?

L’IA ha regalato agli aggressori la velocità. Per colmare questo divario non basta aggiungere un altro strumento: serve decidere come l’intera organizzazione sviluppa e protegge il software. Il codice che viene scritto oggi farà funzionare la tua azienda per anni. Per chi guida la sicurezza, la domanda non è più quanto l’IA permetta di sviluppare più velocemente, ma se i programmi di sicurezza siano in grado di tenere il passo con ciò che l’IA crea.

Quindi non lasciarti distrarre dai numeri. Per qualsiasi programma, poniti tre domande: posso fidarmi di ciò che rileva? Rileva abbastanza di ciò che conta? È realistico implementarlo in tutta l’organizzazione? Combinare la precisione deterministica con il ragionamento dei modelli di frontiera offre le migliori probabilità di rispondere sì a tutte e tre le domande.

Lo sviluppo del software non rallenta. Ora il nostro compito è colmare il divario di rischio: la distanza tra la velocità con cui viene creato il software e quella con cui i rischi vengono individuati e risolti.