🤖 AI

DualGauge: Automated Joint Security-Functionality Benchmarking of Specification-Only Code Generation by LLMs and Coding Agents

Il documento introduce DualGauge, un framework automatizzato e un benchmark che dimostrano come gli attuali LLM e gli agenti di programmazione fatichino a generare simultaneamente codice che sia sia funzionalmente corretto che sicuro, con tassi di successo congiunti che rimangono inferiori al 15% in più linguaggi e rivelando che il potenziamento delle capacità del modello o l'uso di scaffold iterativi non risolvono in modo affidabile i compromessi tra sicurezza e funzionalità.

Autori originali: Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

Pubblicato 2026-06-16

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Rupam Patir, Keyan Guo, Suvadra Barua, Abhijeet Pathak, Dinesh Gudimetla, Jiawei Guo, Hongxin Hu, Haipeng Cai

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di assumere un robot chef molto talentuoso e che parla velocemente per cucinare un pasto basandosi su una semplice descrizione verbale: "Fai un panino".

Per molto tempo, abbiamo solo controllato se il robot avesse seguito la ricetta. Ha messo il pane nel piatto? Sì. Ha aggiunto il prosciutto? Sì. Se il panino sembra quello giusto, diciamo: "Ottimo lavoro!".

Ma questo nuovo articolo, DualGauge, pone una domanda molto più difficile: "Il panino è sicuro da mangiare?"

Forse il robot ha seguito la ricetta alla perfezione, ma ha anche tagliato accidentalmente il prosciutto con un coltello arrugginito trovato nel cassetto, o ha usato un tagliere che non era mai stato lavato. Il panino sembra un panino, ma è pericoloso.

Ecco la storia di ciò che i ricercatori hanno scoperto, spiegata in modo semplice.

1. Il Problema: La trappola del "Sembra buono"

I ricercatori hanno scoperto che gli attuali strumenti di codifica AI (come il robot chef) sono bravissimi a creare cose che sembrano funzionare, ma sono terribili nel creare cose che sono effettivamente sicure.

Hanno costruito un nuovo sistema di test chiamato DualGauge. Immaginatelo come una "Cucina con il doppio controllo".

Il Vecchio Modo: Assaggi il panino. Se sa di prosciutto, superi il test.
Il Modo DualGauge: Assaggi il panino (Funzionalità) E ispezionate la cucina alla ricerca di coltelli arrugginiti, taglieri sporchi e veleno (Sicurezza).

2. Il Benchmark: "I 307 ordini di panini"

Per testare questo, hanno creato un enorme menu di 307 diversi compiti.

Ogni compito era una semplice frase, come "Scrivi un programma che legge un file".
Non hanno dato all'AI alcun suggerimento, frammento di codice o avviso di sicurezza. Solo l'ordine.
Per ogni ordine, hanno creato due set di test:
1. Il Test del Gusto: Il programma fa quello che dovrebbe fare?
2. L'Ispezione di Sicurezza: Il programma cerca di rubare file, far crashare il sistema o lasciare entrare gli hacker?

3. I Risultati Scioccanti

Hanno chiesto a 10 dei modelli AI più intelligenti (gli "chef") di preparare questi 307 panini. Ecco cosa è successo:

Il punteggio "Sembra buono" era alto: Molti modelli hanno ottenuto circa il 39% di panini dal sapore corretto. Hanno seguito la ricetta!
Il punteggio "Sicuro" era basso: Quando si controllava la sicurezza, i punteggi scendevano.
Il punteggio "Perfetto" era minuscolo: Quando hanno chiesto: "Hai fatto un panino che sia buono da mangiare E sicuro?", il miglior modello AI ha ottenuto meno del 15% di successo.

L'Analogia: Immaginate uno studente che sostiene un test di matematica. Ottiene il 90% delle risposte corrette (Correttezza Funzionale). Ma se chiedete: "Hai anche controllato il tuo lavoro per errori di calcolo?", fallisce. L'articolo ha scoperto che essere bravi a programmare non significa automaticamente essere bravi a programmare in modo sicuro.

4. Perché "Pensare di più" non ha aiutato

I ricercatori hanno cercato di risolvere il problema fornendo all'AI più strumenti, proprio come dare a uno chef coltelli migliori o più tempo per pensare. Hanno provato:

Modelli più grandi: Utilizzando i "super-chef" (cervelli AI più grandi).
Pensiero Esteso: Dicendo all'AI: "Prenditi il tuo tempo e pensa passo dopo passo".
Addestramento Specializzato: Insegnando specificamente all'AI come essere un programmatore.

Il Risultato: Nessuna di queste tecniche ha risolto in modo affidabile il problema della sicurezza. A volte l'AI diventava più brava nella ricetta, ma dimenticava ancora di lavare il tagliere. A volte diventava più brava nella sicurezza, ma dimenticava la ricetta. La sicurezza e la funzionalità sono due abilità diverse che non sempre crescono insieme.

5. Nemmeno l' "Assistente Robotico" ha aiutato

Esistono nuovi strumenti AI che agiscono come "agenti". Invece di scrivere semplicemente il codice una volta, cercano di correggere i propri errori. Scrivono il codice, lo eseguono, vedono un errore e riprovano.

I ricercatori hanno scoperto che su questi compiti di "pura ricetta", gli agenti non sono stati migliori dei semplici robot.

Perché? Gli agenti passavano tutto il tempo a cercare strumenti in cucina (come cercare un file specifico o configurare un server) invece di concentrarsi effettivamente sulla sicurezza del panino. Erano impegnati a "gestire la cucina" ma non a "cucinare in modo sicuro".

6. Il "Pericolo Nascosto"

L'articolo ha trovato un modello specifico nel perché l'AI falliva.

Fallimenti Funzionali: L'AI di solito falliva perché sbagliava la "forma" della risposta (ad esempio, restituiva il tipo di dato errato).
Fallimenti di Sicurezza: L'AI di solito cercava di essere sicura, ma era incompleta.
- Esempio: L'AI ha messo una serratura sulla porta (una guardia di sicurezza), ma si è dimenticata di chiudere la finestra sul retro. La guardia sembrava buona, ma la casa era ancora insicura.

Il Punto Fondamentale

L'articolo conclude che non possiamo fidarci dell'AI solo perché scrive codice che "funziona".

La correttezza funzionale è un cattivo rilevatore di bug per la sicurezza. Il fatto che il codice venga eseguito senza crash non significa che sia sicuro.
Abbiamo bisogno di un nuovo standard. Dobbiamo testare la sicurezza e la funzione contemporaneamente, usando le stesse regole.
L'attuale AI non è ancora arrivata. Anche i modelli più intelligenti stanno fallendo nel produrre costantemente codice che sia sia utile che sicuro.

In breve: Solo perché il robot chef ha preparato un panino che sembra delizioso, non significa che tu debba mangiarlo. Dobb di controllare anche la cucina.

Riepilogo Tecnico: DualGauge

Problematica

I Large Language Models (LLM) e gli agenti di codifica basati su LLM sono sempre più utilizzati per generare codice a partire da specifiche in linguaggio naturale. Sebbene la correttezza funzionale sia diventata il criterio dominante per valutare questi sistemi, essa è insufficiente per garantire software distribuibile. Ricerche precedenti indicano che gli assistenti alla codifica IA generano frequentemente codice insicuro, e gli sviluppatori spesso accettano tali suggerimenti pur rimanendo fiduciosi nella loro sicurezza.

Gli attuali framework di valutazione soffrono di due limitazioni primarie:

Isolamento delle Metriche: I benchmark funzionali (es. HumanEval, LiveBench) e i benchmark di sicurezza (es. SecurityEval, CodeLMSec) valutano tipicamente correttezza e sicurezza in isolamento o su dataset differenti. Un programma che supera i test funzionali ma contiene vulnerabilità, o viceversa, non è utile.
Sfide dell'Oracolo di Valutazione: La valutazione della sicurezza non può fare affidamento esclusivamente sul matching esatto dell'output. Come illustrato dagli esempi di path-traversal, un'implementazione sicura e una vulnerabile possono produrre output e codici di uscita identici su input avversari. La distinzione risiede spesso nella traccia di esecuzione (ad esempio, se un file è stato accessato prima che un controllo fallisse), richiedendo un ragionamento semantico sul comportamento a runtime piuttosto che un semplice confronto degli output.
Limitazioni del Contesto: La maggior parte dei benchmark si basa sulla generazione di codice (code completion), sul contesto di repository o sullo scaffolding di framework, trascurando la generazione "solo specifica" dove un modello deve implementare una funzione partendo esclusivamente da una descrizione in linguaggio naturale.

Metodologia: DualGauge e DualGauge-Bench

Gli autori presentano DualGauge, un framework completamente automatizzato per la valutazione congiunta di sicurezza e funzionalità nella generazione di codice basata solo su specifiche, supportato da DualGauge-Bench.

DualGauge-Bench

Si tratta di un benchmark agnostico rispetto al linguaggio composto da 307 task di codifica.

Design del Task: Ogni task consiste in una specifica in linguaggio naturale senza snippet di codice, firme di funzioni o vincoli specifici del linguaggio.
Testing Accoppiato: Ogni specifica è accoppiata a due suite di test derivate dalla stessa prompt:
- Test Funzionali: Guidati dall'analisi dei valori limite (boundary value analysis) e dalla partizione delle classi di equivalenza per verificare la correttezza comportamentale.
- Test di Sicurezza: Guidati dai principi OWASP e CERT per verificare l'assenza di comportamenti insicuri (es. fallimenti della validazione dell'input, problemi di controllo degli accessi).
Copertura: Il benchmark copre sette domini di funzionalità e 90 categorie CWE (Common Weakness Enumeration), coprendo task intraprocedurali e interprocedurali.
Costruzione: Le prompt sono state curate da dataset esistenti (CodeGuard+, SecurityEval, Purple Llama CyberSecEval) e convertite in pure specifiche. Le suite di test sono state create tramite un processo di co-creazione uomo-LLM, in cui gli LLM hanno proposto candidati e i valutatori umani li hanno validati ed estesi.

Sistema DualGauge

Il sistema opera in quattro fasi per automatizzare la pipeline di valutazione:

Generazione Campioni: Il target LLM o l'agente genera $k$ candidati di codice per una data specifica.
Esecuzione Agentica: Un esecutore guidato da LLM esegue i candidati in un ambiente isolato. Classifica i fallimenti in problemi di ambiente, script o codice. Ripara i problemi di ambiente e script (es. pacchetti mancanti, errori di invocazione), ma non altera il codice del candidato stesso. Ciò garantisce che il programma sia eseguibile senza correggere artificialmente la logica del modello.
Valutazione Runtime basata su LLM:
- Oracolo Funzionale: Utilizza il matching esatto dell'output rispetto agli output attesi.
- Oracolo di Sicurezza: Utilizza un LLM per eseguire un giudizio semantico. Analizza il codice candidato, gli output di esecuzione e le tracce di copertura rispetto ai comportamenti di sicurezza attesi. Se il codice utilizza librerie sconosciute, un modello di risoluzione con capacità di ricerca web recupera la documentazione per assistere la valutazione. Questo passaggio determina se il codice ha implementato una difesa genuina o se è semplicemente fallito per caso.
Aggregazione Risultati: Calcola metriche tra cui il tasso di superamento funzionale ($PR$), il tasso di superamento sicuro ($SPR$) e la metrica congiunta secure-pass@k (la probabilità che un singolo campione sia sia funzionalmente corretto che sicuro).

Risultati Chiave

Gli autori hanno valutato 10 LLM rappresentativi (inclusi le famiglie GPT-5, Claude Opus/Sonnet, Llama, Qwen e Gemma) attraverso Python, C++ e JavaScript, nonché 3 sistemi di codifica agentica (Codex, OpenHands, Claude Code).

1. La Correttezza Funzionale Sovrastima l'Affidabilità

Anche i modelli più forti hanno raggiunto un tasso di superamento funzionale di quasi il 39% nei task Python, ma il tasso di successo congiunto sicurezza-funzionalità (secure-pass@1) è rimasto inferiore al 15% in ogni linguaggio. Ciò indica che la correttezza funzionale è un cattivo indicatore della generazione di codice sicuro.

2. I Fattori Lato Modello Non Migliorano Affatto la Performance Congiunta

Lo studio ha analizzato quattro fattori: scala, pensiero esteso (extended thinking), quantizzazione e specializzazione in istruzioni/codice.

Scala: L'aumento della dimensione del modello ha migliorato la fluidità funzionale, ma la copertura della sicurezza si è stabilizzata molto prima delle dimensioni maggiori.
Pensiero Esteso e Specializzazione: Questi fattori hanno spostato le metriche funzionali e di sicurezza in modo differente a seconda della famiglia di modelli e non hanno migliorato in modo affidabile la metrica congiunta.
Conclusione: La generazione di codice sicuro e corretto non emerge semplicemente da una maggiore capacità di codifica; richiede l'applicazione coerente delle conoscenze di sicurezza attraverso tutti i requisiti.

3. I Sistemi Agentici Non Offrono Vantaggi

Lo scaffolding iterativo degli agenti di codifica (Codex, OpenHands, Claude Code) non ha fornito alcun vantaggio rispetto alla generazione diretta per i task basati solo su specifiche.

Meccanismo di Fallimento: Gli agenti hanno speso sforzi significativi in overhead orientati al repository (es. elencare directory, cercare file di configurazione) che non hanno prodotto alcun segnale in uno workspace vuoto.
Ciclo di Feedback: Gli agenti spesso si sono affidati a test autogenerati invece che a benchmark di verità fondamentale (ground-truth). Difese parziali che passavano i controlli interni dell'agente ma fallivano i test di sicurezza del benchmark non sono state riviste. Di conseguenza, gli agenti hanno ereditato gli stessi modi di fallimento della generazione diretta senza colmare il divario di copertura.

4. Modalità di Fallimento

Fallimenti Funzionali: Concentrati al confine del contratto di output (es. struttura JSON errata, CLI vs servizio errato), non in errori algoritmici.
Fallimenti di Sicurezza: Caratterizzati da difese parziali. I modelli hanno spesso implementato guardie (regex, controlli di tipo) che sembravano ragionevoli ma non coprivano il vettore di attacco specifico o erano applicate al livello di astrazione errato.
Gap Congiunto: Un programma poteva superare i test funzionali pur essendo insicuro, o superare alcuni test di sicurezza pur fallendone altri. Solo il benchmarking congiunto ha esposto in modo affidabile questi fallimenti "silenziosi".

Significato e Rivendicazioni

Il documento sostiene di presentare il primo framework completamente automatizzato per la valutazione congiunta di sicurezza e funzionalità nella generazione di codice basata solo su specifiche. La sua importanza risiede nel:

Rivelare il Gap: Dimostrare che gli attuali modelli e agenti all'avanguardia faticano a soddisfare contemporaneamente correttezza e sicurezza, con tassi di successo congiunti che rimangono criticamente bassi (<15%).
Spostamento Metodologico: Argomentare che la valutazione della sicurezza richiede un ragionamento semantico sulle tracce di esecuzione piuttosto che il matching dell'output, e che i benchmark devono accoppiare test funzionali e di sicurezza per la stessa specifica.
Limitazioni degli Agenti: Mostrare che il raffinamento multi-turno e l'uso di strumenti non superano ancora automaticamente la sfida principale di produrre codice sicuro quando non è disponibile un codebase esistente o un test runner per guidare l'agente.
Standard di Benchmark: Fornire un benchmark agnostico rispetto al linguaggio e riutilizzabile (DualGauge-Bench) che va oltre la generazione di codice per testare la capacità fondamentale dei modelli di tradurre l'intento in linguaggio naturale in codice sicuro e corretto.

Gli autori concludono che la generazione di codice sicuro richiede l'applicazione coerente delle conoscenze di sicurezza attraverso l'intero spazio dei requisiti, una capacità che gli attuali modelli e agenti non hanno ancora padroneggiata. Enfatizzano che i loro risultati sono stime di benchmark scalabili e che la revisione umana della sicurezza rimane necessaria.