Il rilevamento delle vulnerabilità AI di AWS intercetta i bug, ma i falsi positivi evidenziano un divario di fiducia

AWS ha testato 12 modelli AI generalisti e ha riscontrato un netto conflitto: individuavano la maggior parte delle vulnerabilità, ma spesso classificavano codice sicuro come pericoloso.

Il nuovo Deception Benchmark sottopone le dichiarazioni sul rilevamento delle vulnerabilità AI di AWS a una prova più severa rispetto a un'altra classifica di ricerca dei bug. Verifica se un modello riesce a riconoscere quando un codice sospetto è in realtà protetto da una mitigazione funzionante. Con prompt diretti, i modelli testati hanno segnalato come vulnerabili tra il 41% e il 99% dei campioni sicuri.

Questo risultato sposta il dibattito sugli strumenti di sicurezza AI. Individuare pattern sospetti non basta quando ogni avviso assorbe tempo di ingegneria. La vera sfida ora è tra il riconoscimento rapido dei pattern e la verifica basata sulle evidenze, e i team di sicurezza ne sostengono il costo.

AWS ha pubblicato il benchmark il 9 settembre 2026, con 14.822 campioni in 16 linguaggi di programmazione e oltre 70 categorie Common Weakness Enumeration. Nessuna configurazione testata ha raggiunto il minimo dichiarato da AWS di mantenere sia il tasso di falsi positivi sia quello di falsi negativi al di sotto del 10%.

AWS ha creato un benchmark in cui il codice sicuro sembra pericoloso

Il benchmark verifica se un modello comprende la sfruttabilità, non se riconosce un pattern di vulnerabilità familiare.

Molte valutazioni della sicurezza partono da software vulnerabile e chiedono a un sistema AI di identificare o sfruttare la falla. Questo approccio rivela utili capacità offensive, ma offre un quadro incompleto delle prestazioni difensive. Un revisore in produzione deve anche poter escludere codice che assomiglia a una vulnerabilità senza creare un reale percorso di attacco.

AWS ha progettato Deception Benchmark attorno a questa distinzione. I suoi campioni sicuri contengono framework realistici, flussi di dati dall'aspetto pericoloso e segnali di sicurezza riconoscibili. Una mitigazione sottile chiude il percorso di sfruttamento, lasciando al modello il compito di stabilire se la protezione funzioni davvero.

Un esempio descritto nel rilascio del benchmark riguarda un endpoint Flask che accetta input utente e interroga un database. Il pattern circostante ricorda un'iniezione SQL. Tuttavia, le istruzioni parametrizzate impediscono che l'input diventi sintassi eseguibile della query.

Un modello che si ferma al riconoscimento del pattern segnalerà una vulnerabilità. Un modello che segue l'intero flusso di dati dovrebbe classificare il campione come sicuro. Questa differenza determina se l'output diventa un'evidenza utile o un altro avviso che richiede un'indagine manuale.

Il benchmark include 6.988 sfide a livello di codice. Presentano varianti vulnerabili e sicure che differiscono per una correzione sottile. Entrambe le versioni possono apparire sospette, ma solo una resta sfruttabile.

Altre 2.707 sfide aggiungono il contesto di deployment. Il codice sorgente potrebbe sembrare vulnerabile mentre un controllo dell'infrastruttura blocca l'attacco. Gli esempi includono una Kubernetes Network Policy che impedisce una server-side request forgery o un confine di identità che previene l'escalation dei privilegi.

Questi casi vincolati dall'ambiente sono importanti perché la sicurezza aziendale raramente termina in un singolo file. La sfruttabilità dipende dalla configurazione, dalla raggiungibilità di rete, dalle autorizzazioni, dal comportamento in esecuzione e dai controlli compensativi. Uno scanner che ignora queste condizioni può descrivere un attacco plausibile che non può verificarsi nell'ambiente distribuito.

AWS afferma che ogni campione è stato creato per il benchmark e basato su pattern di sicurezza reali. L'azienda ha utilizzato un ciclo di sviluppo avversariale che ha generato le sfide, le ha testate rispetto ai modelli di frontiera, ha reso più robuste le casistiche semplici e ha ripetuto il processo.

Questo metodo rende il dataset intenzionalmente difficile. Significa inoltre che i risultati non dovrebbero essere trattati come un tasso di errore rappresentativo per ogni repository sorgente. Il benchmark seleziona casi progettati per mettere in luce ragionamenti superficiali, non un campione casuale di revisioni di codice quotidiane.

Il suo valore deriva dall'isolare una capacità specifica. Un modello riesce a seguire una catena di sfruttamento abbastanza a lungo da distinguere una debolezza effettiva da un'esca convincente? Questa domanda è al centro di un affidabile rilevamento delle vulnerabilità AI di AWS.

Il repository pubblico del benchmark contiene tutti i 14.822 campioni. AWS ne valuta 9.695 e ne lascia 5.127 senza punteggio. Questi campioni esclusi includono casi contestati o deliberatamente ambigui.

Le etichette non sono incluse pubblicamente. I partecipanti devono inviare previsioni per ogni campione, comprese le spiegazioni, prima che AWS restituisca i risultati di accuratezza e tasso di errore. Questo approccio mira a limitare la memorizzazione e l'ottimizzazione specifica per il benchmark.

AWS afferma inoltre che revisori indipendenti hanno esaminato ripetutamente le etichette. I campioni contestati sono stati spostati nel gruppo senza punteggio invece di ricevere etichette corrette. Secondo l'azienda, una revisione umana di 100 campioni valutati selezionati casualmente non ha rilevato errori.

Ciò non rende il dataset immune dalle critiche. I ricercatori indipendenti devono ancora esaminarne la costruzione, il bilanciamento delle categorie, il processo di valutazione e il trasferimento al mondo reale. Tuttavia, il rilascio offre ai team esterni un obiettivo comune per confrontare i sistemi nelle stesse condizioni avversariali.

I risultati del rilevamento delle vulnerabilità AI di AWS rivelano due cattive alternative

I prompt diretti producono troppi falsi allarmi, mentre requisiti di prova più rigorosi portano i modelli a non rilevare più vulnerabilità reali.

AWS ha valutato 12 modelli di cinque fornitori usando due strategie di prompting. Il prompting diretto chiedeva a ciascun modello di classificare il codice come vulnerabile o sicuro. Il prompting con prova di sfruttamento richiedeva di costruire un exploit concreto prima di dichiarare una vulnerabilità.

Il benchmark separa due tipi di errore perché generano fallimenti operativi diversi. Un falso positivo etichetta codice sicuro come vulnerabile. Un falso negativo classifica una vulnerabilità reale come sicura.

Con prompt diretti, i modelli hanno generalmente privilegiato la sensibilità. Secondo AWS, hanno individuato fino al 95% delle vulnerabilità reali. Tuttavia, hanno anche segnalato come vulnerabile dal 41% al 99% del codice sicuro.

Questo bias può far apparire un modello attivo e prudente. È anche un modo semplice per proteggere il recall, che misura la quota di vulnerabilità reali individuate. Un sistema che definisce tutto vulnerabile non mancherà mai una vulnerabilità, ma sommergerà gli utenti di avvisi inutili.

Mistral Large illustra questa modalità di fallimento. La sua configurazione con prompt diretto ha registrato un tasso di falsi positivi del 99% e un tasso di falsi negativi dello 0%. Ha individuato i casi vulnerabili trattando praticamente ogni caso sicuro come pericoloso.

Diverse altre configurazioni dirette si sono comportate in modo simile. GPT-5.6 Sol ha registrato un tasso di falsi positivi del 92,5% e un tasso di falsi negativi dello 0,9%. Claude Haiku 4.5 ha raggiunto un tasso di falsi positivi del 92,1% senza registrare falsi negativi.

Nemmeno Nova 2 Lite di Amazon ne è stato esente. Con il prompting diretto, AWS ha riportato un tasso di falsi positivi dell'89,2% e un tasso di falsi negativi dell'1,2%. L'inclusione del modello Amazon contribuisce a rendere il rilascio più di un confronto rivolto ai fornitori esterni.

Claude Opus 5 ha prodotto il miglior equilibrio con prompt diretto tra i sistemi elencati. Ha raggiunto un'accuratezza del 77,3%, con un tasso di falsi positivi del 41,5% e un tasso di falsi negativi del 5,2%. Anche questo risultato restava ben oltre la soglia di produzione dichiarata da AWS.

La sola accuratezza nasconde queste differenze. Il benchmark è approssimativamente bilanciato tra casi sicuri e vulnerabili, quindi un classificatore che risponde sempre “vulnerabile” può ottenere un punteggio vicino al 50%. La sua apparente accuratezza cela il fatto che ogni campione sicuro diventa un avviso.

AWS ha quindi fissato quella che ha definito una soglia minima generosa. Una configurazione pronta per la produzione dovrebbe mantenere entrambi i tassi di errore sotto il 10%. Nessuna delle configurazioni testate ha raggiunto questo obiettivo.

I risultati diretti mostrano perché il rilevamento delle vulnerabilità AI non può essere valutato solo dal recall. Individuare quasi ogni falla reale sembra rassicurante finché un team non scopre che anche la maggior parte del codice sicuro ha generato avvisi.

Non si tratta di un problema estetico di qualità. Ogni falso avviso entra in un flusso di lavoro. Qualcuno deve ispezionare il codice, riprodurre il percorso presunto, controllare la configurazione, consultare il team responsabile e documentare perché il rilevamento può essere chiuso.

Su scala aziendale, questo costo di revisione può annullare il vantaggio di velocità promesso dall'automazione. Può inoltre creare affaticamento da avvisi, per cui gli ingegneri iniziano a ignorare i rilevamenti perché troppi avvisi precedenti erano errati.

La conseguenza per la sicurezza è scomoda. Un elevato tasso di falsi positivi può indirettamente aumentare il rischio anche quando il modello ha un recall eccellente. L'avviso importante compete per l'attenzione con decine di errori convincenti.

Precedenti lavori accademici hanno identificato lo stesso schema. Una valutazione di sicurezza del 2024 ha testato otto modelli linguistici in 228 scenari di codice e ha riportato elevati tassi di falsi positivi. I modelli talvolta continuavano a segnalare vulnerabilità dopo che il codice testato era stato corretto.

Lo studio ha inoltre rilevato risposte non deterministiche e ragionamenti fragili a fronte di semplici modifiche del codice. Il rilascio più ampio di AWS estende la preoccupazione a più linguaggi, categorie di debolezza, modelli ed esempi sicuri costruiti in modo avversariale.

La prova di sfruttamento riduce il rumore ma crea un nuovo punto cieco

Richiedere evidenze migliora la disciplina, ma i modelli testati hanno spesso ottenuto tale precisione trascurando vulnerabilità autentiche.

Il prompting con prova di sfruttamento chiede a un modello di andare oltre il sospetto. Prima di etichettare il codice come vulnerabile, deve descrivere un percorso concreto che un attaccante potrebbe utilizzare. Questo modifica la soglia decisionale da “sembra pericoloso” a “posso spiegare come funziona l'attacco”.

AWS ha riportato che questa strategia ha ridotto i tassi di falsi positivi tra 17 e 74 punti percentuali. È un miglioramento significativo. Ha però aumentato i tassi di falsi negativi, compresi tra il 7% e il 44% con l'approccio più rigoroso.

GPT-5.4 offre l'esempio più chiaro del compromesso. La sua configurazione diretta ha prodotto un tasso di falsi positivi dell'81% e un tasso di falsi negativi dell'1,5%. Il prompting con prova di sfruttamento ha ridotto i falsi positivi al 10,1%, ma i falsi negativi sono saliti al 33,6%.

Llama 3.3 70B ha seguito uno schema simile. Il suo tasso di falsi positivi è sceso dall'84,2% al 10,2%. Il suo tasso di falsi negativi è salito dall'1,1% al 44,2%, il che significa che la configurazione ha mancato quasi metà delle vulnerabilità valutate.

Claude Opus 5 ha registrato la più alta accuratezza complessiva, il 79,3%, con il prompting con prova di sfruttamento. Tuttavia, il suo tasso di falsi positivi del 24,9% e quello di falsi negativi del 16,8% restavano entrambi al di sopra della soglia di AWS.

I risultati non significano che il prompting con prova di sfruttamento sia inefficace. Mostrano che il prompting cambia quali errori commette un modello. I responsabili della sicurezza devono decidere se il loro flusso di lavoro possa assorbire più falsi allarmi, più falle non rilevate o una combinazione attentamente misurata.

Questa decisione dipende dall'applicazione. La revisione di un servizio di autenticazione esposto a Internet dovrebbe tollerare meno vulnerabilità non rilevate. Un repository interno a basso rischio potrebbe privilegiare la precisione per evitare di esaurire un piccolo team di ingegneria.

Anche la gravità dovrebbe influenzare la soglia. Un sistema potrebbe indirizzare i rilevamenti critici ad alta confidenza a una revisione umana immediata, gestendo al contempo gli avvisi più deboli tramite una convalida a priorità inferiore. È improbabile che un'unica soglia di classificazione globale sia adatta a ogni codebase.

È qui che il design a singolo turno del benchmark diventa importante. AWS ha deliberatamente rimosso l'infrastruttura degli agenti, gli strumenti esterni e i cicli di validazione ripetuti. L'obiettivo era misurare il ragionamento intrinseco del modello di base anziché un prodotto commerciale di sicurezza completo.

Pertanto, i risultati non dimostrano che ogni scanner agentico abbia gli stessi tassi di errore. Un prodotto potrebbe combinare modelli linguistici con analisi statica, test dinamici, contesto del repository, controlli delle policy e validazione deterministica degli exploit. Questi componenti possono modificare il punto operativo.

AWS riconosce esplicitamente questa distinzione. Il suo benchmark accetta separatamente le proposte agentiche rispetto ai risultati dei modelli a singolo turno. Questa separazione impedisce che un sistema assistito da strumenti venga presentato come equivalente a una chiamata a un modello senza supporto.

L'avvertenza non rende irrilevante la baseline. Ogni flusso di lavoro agentico eredita alcune limitazioni dal modello sottostante. Ripetere un giudizio debole può produrre una spiegazione più elaborata senza aggiungere il fatto tecnico mancante.

Un sistema ha bisogno di una fonte affidabile di nuove evidenze. Potrebbe eseguire un test, tracciare i dati tra file, ispezionare una policy di deployment o verificare se un endpoint è raggiungibile. Le sole chiamate multiple al modello non garantiscono una comprensione più profonda.

Il compito più difficile è dimostrare la sicurezza. I test offensivi spesso forniscono un risultato visibile perché un exploit riesce o fallisce. Un tentativo fallito non dimostra che non esista alcun altro exploit, quindi l'assenza di successo resta difficile da interpretare.

Gli esempi di AWS vincolati dall'ambiente rendono il problema più netto. Un modello deve ragionare tra codice e infrastruttura, quindi riconoscere che una mitigazione blocca il percorso che aveva inizialmente individuato. AWS afferma che i modelli spesso rilevavano il pattern rischioso ma ignoravano il controllo nelle vicinanze.

Questo comportamento ricorda un comune bias umano nella revisione di sicurezza. Una volta che un revisore riconosce una forma familiare di vulnerabilità, la conferma può arrivare più rapidamente della confutazione. I modelli linguistici amplificano il problema perché il riconoscimento dei pattern è centrale nel modo in cui generano risposte.

Per gli acquirenti, la lezione pratica è specifica. Chiedete se un prodotto di sicurezza AI verifica la sfruttabilità e come misura entrambi i tassi di errore. Un dato sul richiamo senza dati sui falsi positivi rivela poco sul carico di lavoro creato dal prodotto.

I sistemi di sicurezza AWS mostrano perché l'architettura conta

Le dichiarazioni di AWS in produzione si basano su agenti stratificati, controlli deterministici e approvazione umana, non su un modello senza supporto che decide se il codice è sicuro.

Il benchmark è arrivato mesi dopo che AWS aveva descritto due sistemi di sicurezza agentici. Quelle precedenti divulgazioni offrono un importante contrappunto perché mostrano come Amazon tenti di gestire le limitazioni ora misurate direttamente.

RuleForge genera regole di rilevamento a partire da esempi di exploit disponibili pubblicamente. AWS afferma che il sistema ha aumentato la produttività nella produzione di regole del 336% rispetto a un processo manuale negli ultimi quattro mesi del 2025.

La sua architettura divide il compito tra fasi specializzate. Un componente acquisisce e assegna priorità alle informazioni sulle vulnerabilità. Gli agenti di generazione propongono diverse regole di rilevamento. Un giudice separato le valuta, test sintetici le esercitano e i dati sul traffico supportano un'ulteriore validazione.

Un ingegnere della sicurezza resta il passaggio finale di approvazione. Questo ruolo umano conta perché RuleForge non considera la fiducia di un modello AI come prova sufficiente per il deployment.

AWS ha dichiarato che il modello di generazione valutava molto positivamente quasi ogni regola quando gli veniva chiesto di giudicare il proprio lavoro. Spostare la valutazione su un modello separato ha ridotto i falsi positivi del 67%, preservando al contempo il numero di rilevamenti veri positivi, secondo l'analisi di RuleForge dell'azienda.

Il giudice ha ricevuto anche domande specifiche del dominio. Invece di chiedere se una regola apparisse corretta, il sistema chiedeva se potesse non rilevare richieste dannose. Verificava inoltre se una regola catturasse il meccanismo della vulnerabilità o soltanto una caratteristica superficiale correlata.

Questa distinzione rispecchia Deception Benchmark. Un'espressione permissiva potrebbe corrispondere a input contenenti un apice singolo, ma la corrispondenza con il carattere non prova una SQL injection. La regola deve distinguere il comportamento dell'exploit dal traffico benigno che condivide la stessa caratteristica.

AWS Security Agent utilizza una strategia correlata per i test di penetrazione automatizzati. Agenti specializzati esplorano le applicazioni e producono risultati candidati, mentre i validatori richiedono prove di sfruttamento.

AWS ha riferito che il suo sistema ha ottenuto un tasso di successo degli attacchi del 92,5% su CVE Bench v2.0 quando riceveva istruzioni capture-the-flag e feedback del correttore. Il tasso è sceso all'80% senza questi aiuti e ha raggiunto il 65% con un modello la cui data limite di addestramento precedeva il benchmark.

Questi numeri misurano il successo offensivo, non la precisione difensiva. CVE Bench contiene applicazioni vulnerabili e verifica se gli agenti riescono a sfruttare difetti noti. Non risponde a quanto spesso il sistema accuserebbe codice sicuro.

Ciononostante, l'architettura agentica illustra una risposta credibile alla debolezza del benchmark. I risultati candidati vengono sottoposti a controlli deterministici e basati su modelli, mentre i report includono prove di sfruttamento e contesto tecnico.

Questo crea un'apparente contraddizione solo se “rilevamento delle vulnerabilità AI” viene trattato come un'unica tecnica. Il benchmark del modello di base espone un giudizio debole in un singolo passaggio. I sistemi di produzione di AWS dichiarano di ricavare valore da flussi di lavoro che raccolgono evidenze e vincolano quel giudizio.

Il confronto supporta una conclusione più precisa. I modelli generalisti sono componenti utili per l'automazione della sicurezza, ma è il sistema che li circonda a determinare se il loro output meriti fiducia operativa.

Un fornitore non può colmare il divario applicando l'etichetta di agente a prompt ripetuti. Le domande rilevanti riguardano strumenti, evidenze, calibrazione, gestione dei fallimenti e supervisione umana. Gli acquirenti dovrebbero chiedere cosa cambia tra il primo sospetto e il risultato finale.

Il prodotto esegue il percorso ritenuto vulnerabile? Ispeziona i controlli dell'infrastruttura? Può tracciare i dati oltre i confini del repository? Confronta i risultati con analizzatori deterministici? Un revisore può vedere perché il risultato ha superato la validazione?

I team necessitano anche di un contesto duraturo durante l'indagine. Note architetturali, eccezioni precedenti, modelli di minaccia e decisioni di remediation spesso sono distribuiti tra documenti e conversazioni. Una base di conoscenza ingegneristica ricercabile può aiutare i revisori a recuperare quel contesto, anche se non sostituisce la validazione tecnica.

Le valutazioni di procurement dovrebbero distinguere tre livelli. Il primo è il modello sottostante, per il quale Deception Benchmark offre una baseline comune. Il secondo è l'architettura di validazione, che determina come il sistema raccolga evidenze aggiuntive. Il terzo è il processo operativo, inclusi la responsabilità della revisione e il rischio accettabile.

Un prodotto può funzionare bene a un livello e male a un altro. Un modello capace può essere indebolito da prompt vaghi e contesto mancante. Un modello meno capace può diventare più utile quando strumenti circoscritti e una validazione rigorosa vincolano le sue decisioni.

Le divulgazioni di AWS contengono inoltre risultati riportati dall'azienda, non audit indipendenti delle prestazioni in produzione. L'affermazione di produttività del 336% e la riduzione del 67% dei falsi positivi descrivono RuleForge nella valutazione di Amazon. Non dovrebbero essere generalizzate a repository o prodotti non correlati.

Questa incertezza rafforza l'argomento a favore di un benchmark pubblico. I fornitori possono sottoporre i propri sistemi completi a Deception Benchmark e riportare risultati agentici separati. I clienti possono quindi confrontare affermazioni formulate nell'ambito di un'attività condivisa, invece di affidarsi a case study incompatibili.

I falsi positivi trasformano la velocità dell'AI in lavoro umano

Il rischio aziendale non è che l'AI non trovi nulla; è che errori plausibili assorbano le persone necessarie per confermare i risultati reali.

Gli strumenti di sicurezza hanno da tempo difficoltà con i falsi positivi. I tradizionali test statici di sicurezza delle applicazioni analizzano il codice sorgente alla ricerca di flussi o costrutti pericolosi, spesso senza un contesto completo di runtime. L'AI promette un migliore ragionamento semantico, ma i risultati di AWS mostrano che i pattern riconoscibili esercitano ancora una forte attrazione.

Considerate un team di sviluppo che riceve un avviso urgente di SQL injection. Un ingegnere interrompe il lavoro pianificato, individua il responsabile pertinente, esamina il percorso della query e conferma che il binding dei parametri impedisce l'injection. L'avviso necessita poi di note di chiusura affinché non si riapra durante la scansione successiva.

Un errore sembra gestibile. Migliaia di repository e scansioni frequenti cambiano il calcolo. Un alto tasso di falsi positivi trasforma il rilevamento automatizzato in una coda ricorrente di verifiche manuali.

Quella coda crea diverse forme di costo. Il lavoro di ingegneria rallenta perché la remediation interrompe la consegna delle funzionalità. I team di sicurezza spendono tempo a difendere la credibilità dello scanner. I responsabili delle applicazioni imparano a trattare gli avvisi come suggerimenti non verificati.

Alla fine, la fiducia si erode. Una vulnerabilità reale può arrivare attraverso lo stesso canale e ricevere la stessa risposta scettica. Il sistema di rilevamento ha comunque “trovato” il difetto, ma operativamente non è riuscito a produrre un'azione tempestiva.

I falsi negativi creano il pericolo opposto. Un sistema più rigoroso può ridurre le interruzioni segnalando meno problemi, ma il suo silenzio diventa meno affidabile se non rileva una quota consistente di difetti autentici.

Per questo la doppia soglia di AWS è importante. Misurare solo la precisione premia sistemi conservativi che non segnalano quasi nulla. Misurare solo il richiamo premia sistemi aggressivi che segnalano quasi tutto. Le decisioni di produzione necessitano di entrambi i valori, segmentati per gravità della vulnerabilità e contesto del codice.

I team dovrebbero anche chiedere come un fornitore abbia stabilito la verità di riferimento. Le etichette delle vulnerabilità sono difficili perché il codice può essere sicuro per ragioni esterne alla funzione visibile. Dipendenze, configurazione, autenticazione, controlli di rete e stato di deployment possono modificare la sfruttabilità.

Il team di Deception Benchmark ha cercato di limitare gli errori di etichettatura tramite revisioni indipendenti ripetute ed escludendo dalla valutazione i casi contestati. È una scelta progettuale ponderata, ma introduce un'altra domanda. Quanto assomigliano i suoi campioni giudicati in modo chiaro all'ambiguità dei sistemi aziendali reali?

I repository reali contengono test incompleti, assunzioni non documentate, configurazioni obsolete, codice generato e lacune nella responsabilità. Uno strumento potrebbe dover dire che le evidenze sono insufficienti anziché imporre una risposta binaria vulnerabile-o-sicuro.

Il benchmark richiede attualmente questa decisione binaria. Sono richieste spiegazioni dettagliate, ma l'astensione non è elencata come esito valutato. Le future valutazioni potrebbero esaminare se un'incertezza calibrata aiuti i team ad allocare lo sforzo di revisione.

Anche latenza e costo meritano attenzione. Un sistema multi-agente potrebbe ridurre i falsi positivi eseguendo test e ispezionando un contesto più ampio. Questo miglioramento potrebbe richiedere più capacità di calcolo, tempi di revisione più lunghi e accesso a codice o infrastruttura sensibili.

Questi compromessi non invalidano la verifica agentica. Determinano dove essa sia appropriata. Le modifiche ad alto rischio possono giustificare un'analisi più approfondita, mentre il codice di routine può richiedere uno screening più economico seguito da un'escalation selettiva.

I responsabili della sicurezza dovrebbero evitare di sostituire una metrica di facciata con un'altra. Un punteggio complessivo di accuratezza nasconde la direzione dell'errore. Un dato spettacolare sulla produttività può nascondere l'onere della revisione. Un impressionante tasso di successo degli exploit dice poco sul codice sicuro.

Una valutazione credibile dovrebbe rivelare almeno cinque elementi: tasso di falsi positivi, tasso di falsi negativi, copertura, metodo di validazione e prestazioni per categoria di debolezza. Dovrebbe inoltre identificare rifiuti e output non validi invece di rimuoverli silenziosamente.

La copertura ha interessato un risultato AWS. La maggior parte delle configurazioni ha restituito risposte valide per almeno il 98% dei campioni. GPT-5.6 Sol, con prompt orientati alla dimostrazione di exploit, ha raggiunto il 93%, perché un filtro di sicurezza del provider ha rifiutato alcune richieste di costruzione dell’exploit.

Questo dettaglio evidenzia un altro vincolo della produzione. Gli agenti di sicurezza talvolta devono ragionare su tecniche dannose per convalidare le difese. I controlli di sicurezza dei modelli possono bloccare valutazioni legittime, creando risultati mancanti che devono essere misurati anziché ignorati.

Per gli acquirenti aziendali, la posizione migliore nel breve termine è l’assistenza controllata. Lasciate che l’AI stabilisca le priorità, spieghi e raccolga le prove. Mantenete la verifica umana sui percorsi di codice ad alto rischio, soprattutto quando il contesto di distribuzione o la logica di business determina se un attacco funziona.

La proposta di valore diventa quindi più circoscritta, ma anche più difendibile. L’AI può ridurre i tempi di ricerca e far emergere ipotesi. Non dovrebbe ricevere autorità unilaterale solo perché il suo output utilizza un linguaggio tecnico sicuro di sé.

Cosa dovrebbero osservare i team di sicurezza

Il benchmark diventa rilevante solo se i fornitori testano sistemi completi, pubblicano tassi di errore equilibrati e dimostrano che i miglioramenti resistono su repository reali.

Il primo segnale è la partecipazione. AWS invita gli sviluppatori a eseguire tutti i 14.822 campioni e a inviare previsioni per una valutazione verificata. I sistemi multi-step con strumenti vengono valutati separatamente dai modelli a singolo turno.

Le proposte indipendenti riveleranno se la verifica agentica colma il divario misurato. Se i sistemi completi riducono entrambi i tassi di errore sotto il 10%, i risultati sosterrebbero la tesi di AWS secondo cui l’architettura può compensare un giudizio di base debole. In caso contrario, il problema della fiducia è più profondo.

Il secondo segnale è la riproducibilità. I ricercatori dovrebbero esaminare i campioni pubblicati, le categorie di sfida, il gruppo non valutato e il processo delle etichette nascoste. Valutazioni comparabili condotte da gruppi indipendenti mostrerebbero se le classifiche dei modelli e gli schemi di fallimento persistono al di fuori del metodo di costruzione di AWS.

Il terzo segnale è l’evidenza in produzione. I fornitori dovrebbero rendere noto quanti avvisi gli utenti analizzano, ignorano, riaprono e infine correggono. Questi risultati del flusso di lavoro contano più del punteggio di classificazione isolato di un modello.

Il benchmark offre inoltre agli acquirenti una richiesta di proposta migliore. Chiedete ai fornitori di sottoporre i propri sistemi e condividere tassi verificati di falsi positivi e falsi negativi. Poi chiedete come cambia il loro processo di convalida per il codice critico, le segnalazioni vincolate dall’ambiente e i linguaggi non supportati.

Gli sviluppatori dovrebbero osservare come gli strumenti presentano l’incertezza. Un revisore utile dovrebbe distinguere tra percorsi di exploit confermati, preoccupazioni plausibili e contesto mancante. Trattare queste categorie come identiche produce lavoro evitabile e nasconde il reale grado di fiducia del sistema.

La ricerca AWS sul rilevamento delle vulnerabilità tramite AI non ha dimostrato che la revisione della sicurezza con l’AI sia inutile. Ha dimostrato perché il rilevamento senza una verifica disciplinata resta costoso e rischioso.

Il prossimo test spetta ai team di prodotto e agli acquirenti. Pretendete prove che una segnalazione resista al tracciamento del codice, ai controlli ambientali e a una convalida riproducibile prima di arrivare a un ingegnere come lavoro urgente. Il vostro fornitore di sicurezza pubblicherà entrambi i tipi di errore, oppure continuerà a vendere velocità senza rivelare la coda di revisione che vi sta dietro?