🤖 AI

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

Het artikel introduceert DualGauge, een geautomatiseerd framework en benchmark die aantoont dat huidige LLM's en programmeeragenten moeite hebben met het gelijktijdig genereren van code die zowel functioneel correct als veilig is, waarbij de gezamenlijke succespercentages onder de 15% blijven over meerdere talen en onthullend dat verbeterde modelcapaciteiten of iteratieve scaffolding de spanning tussen beveiliging en functionaliteit niet betrouwbaar oplossen.

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

Gepubliceerd 2026-06-16

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer getalenteerde, snel pratende robotchef inhuurt om een maaltijd te bereiden op basis van een eenvoudige verbale beschrijving: "Maak een sandwich."

Een lange tijd hebben we alleen gecontroleerd of de robot het recept volgde. Heeft hij brood op het bord gelegd? Ja. Heeft hij ham toegevoegd? Ja. Als de sandwich er goed uitziet, zeggen we: "Goed gedaan!"

Maar dit nieuwe paper, DualGauge, stelt een veel moeilijkere vraag: "Is de sandwich veilig om te eten?"

Misschien heeft de robot het recept perfect gevolgd, maar heeft hij per ongeluk ook de ham gesneden met een roestig mes dat hij in de lade vond, of heeft hij een snijplank gebruikt die nooit is schoongemaakt. De sandwich lijkt op een sandwich, maar hij is gevaarlijk.

Dit is het verhaal van wat de onderzoekers ontdekten, eenvoudig uitgelegd.

1. Het Probleem: De "Ziet Er Goed Uit"-valstrik

De onderzoekers ontdekten dat huidige AI-coderingstools (zoals de robotchef) geweldig zijn in het maken van dingen die eruitzien alsof ze werken, maar ze zijn verschrikkelijk in het maken van dingen die daadwerkelijk veilig zijn.

Ze bouwden een nieuw testsysteem genaamd DualGauge. Denk aan dit als een "Dubbelcheck-Keuken."

De Oude Manier: Je proeft de sandwich. Als het naar ham smaakt, slaag je voor de test.
De DualGauge-Manier: Je proeft de sandwich (Functionaliteit), EN je inspecteert de keuken op roestige messen, vuile planken en gif (Beveiliging).

2. De Benchmark: De "307 Sandwichbestellingen"

Om dit te testen, creëerden ze een enorme menukaart van 307 verschillende taken.

Elke taak was slechts een eenvoudige zin, zoals "Schrijf een programma dat een bestand leest."
Ze gaven de AI geen hints, codestukken of veiligheidswaarschuwingen. Alleen de bestelling.
Voor elke bestelling maakten ze twee sets tests:
1. De Smaaktest: Doet het programma wat het moet doen?
2. De Veiligheidsinspectie: Probeert het programma bestanden te stelen, het systeem te laten crashen of hackers binnen te laten?

3. De Schokkende Resultaten

Ze vroegen 10 van de slimste AI-modellen (de "chefs") om deze 307 sandwiches te maken. Dit is wat er gebeurde:

De "Ziet Er Goed Uit"-score was hoog: Veel modellen kregen ongeveer 39% van de sandwiches goed qua smaak. Ze volgden het recept!
De "Veilig"-score was laag: Bij het controleren op veiligheid daalden de scores.
De "Perfecte"-score was Minuscuul: Wanneer ze vroegen: "Heb je een sandwich gemaakt die goed smaakt EN veilig is?", haalde het beste AI-model minder dan 15% goed.

De Analogie: Stel je een student voor die een wiskundetoets maakt. Hij krijgt 90% van de antwoorden goed (Functionele Correctheid). Maar als je vraagt: "Heb je ook je werk gecontroleerd op rekenfouten?", dan zakt hij. Het paper vond dat goed zijn in coderen niet automatisch betekent dat je goed bent in veilig coderen.

4. Waarom "Harder Denken" Niet Hielp

De onderzoekers probeerden het probleem op te lossen door de AI meer hulpmiddelen te geven, net zoals je een chef betere messen geeft of meer tijd laat om na te denken. Ze probeerden:

Grotere Modellen: Het gebruik van "super-chefs" (grotere AI-hersenen).
Verlengd Denken: De AI vertellen: "Neem de tijd en denk stap voor stap."
Gespecialiseerde Training: De AI specifiek leren hoe een programmeur te zijn.

Het Resultaat: Geen van deze trucjes loste het veiligheidsprobleem betrouwbaar op. Soms werd de AI beter in het recept, maar vergat het nog steeds de snijplank schoon te maken. Soms werd het beter in veiligheid, maar vergat het het recept. Veiligheid en Functionaliteit zijn twee verschillende vaardigheden die niet altijd samen groeien.

5. De "Robotassistent" Hielp Ook Niet

Er zijn nieuwe AI-tools die fungeren als "agents". In plaats van alleen de code één keer te schrijven, proberen ze hun eigen fouten te herstellen. Ze schrijven code, draaien het, zien een fout, en proberen het opnieuw.

De onderzoekers ontdekten dat op deze "pure recept"-taken, de agents niet beter presteerden dan de eenvoudige robots.

Waarom? De agents besteedden al hun tijd aan het zoeken naar gereedschap in de keuken (zoals het zoeken naar een specifiek bestand of het opzetten van een server) in plaats van het daadwerkelijk herstellen van de veiligheid van de sandwich. Ze waren druk bezig met het "managen van de keuken" maar niet met het "veilig koken."

6. Het "Verborgen Gevaar"

Het paper vond een specifiek patroon in waarom de AI faalde.

Functionele Fouten: De AI faalde meestal omdat het de "vorm" van het antwoord fout had (bijv. het leverde het verkeerde type data).
Beveiligingsfouten: De AI probeerde meestal wel veilig te zijn, maar het was onvolledig.
- Voorbeeld: De AI plaatste een slot op de deur (een beveiligingsbewaker), maar vergat het achterste raam te vergrendelen. De bewaker zag er goed uit, maar het huis was nog steeds onveilig.

De Kernboodschap

Het paper concludeert dat we AI niet simpelweg kunnen vertrouwen omdat het code schrijft die "werkt."

Functionele correctheid is een slechte leugendetector voor veiligheid. Alleen omdat code draait zonder te crashen, betekent niet dat het veilig is.
We hebben een nieuwe standaard nodig. We moeten testen op veiligheid en functionaliteit tegelijkertijd, met dezelfde regels.
Huidige AI is er nog niet. Zelfs de slimste modellen slagen er niet in om consistent code te produceren die zowel nuttig als veilig is.

Kortom: Alleen omdat de robotchef een sandwich heeft gemaakt die er heerlijk uitziet, betekent niet dat je hem moet eten. We moeten ook de keuken controleren.

Technische Samenvatting: DualGauge

Probleemstelling

Large Language Models (LLMs) en op LLM gebaseerde coding agents worden steeds vaker gebruikt om code te genereren op basis van natuurlijke taal-specificaties. Hoewel functionele correctheid de dominante criteria is geworden voor het evalueren van deze systemen, is dit onvoldoende om de inzetbaarheid van software te garanderen. Voorlopig onderzoek wijst uit dat AI-assistenten voor coderen frequent onveilige code genereren, en ontwikkelaars accepteren deze suggesties vaak terwijl ze vol vertrouwen zijn over de veiligheid.

Bestaande evaluatieframeworks lijden onder twee primaire beperkingen:

Isolatie van Metrieken: Functionele benchmarks (bijv. HumanEval, LiveBench) en security-benchmarks (bijv. SecurityEval, CodeLMSec) evalueren correctheid en veiligheid doorgaans geïsoleerd of op verschillende datasets. Een programma dat functionele tests doorstaat maar kwetsbaarheden bevat, of andersom, is niet bruikbaar.
Uitdagingen bij de Evaluatie-Oracle: Evaluatie van veiligheid kan niet uitsluitend vertrouwen op exacte output-matching. Zoals geïllustreerd door voorbeelden van path-traversal, kunnen een veilige en een kwetsbare implementatie identieke outputs en exit-codes produceren bij adversariële inputs. Het onderscheid ligt vaak in de uitvoeringstrace (bijv. of een bestand werd geraadpleegd voordat een controle faalde), wat semantische redenering over runtime-gedrag vereist in plaats van eenvoudige output-vergelijking.
Contextbeperkingen: De meeste benchmarks vertrouwen op code-aanvulling, repository-context of framework-scaffolding, waarbij zij "specification-only" generatie over het hoofd zien, waarbij een model een functie moet implementeren op basis van enkel een beschrijving in natuurlijke taal.

Methodologie: DualGauge en DualGauge-Bench

De auteurs presenteren DualGauge, een volledig geautomatiseerd framework voor de gezamenlijke evaluatie van veiligheid en functionaliteit in specification-only code-generatie, ondersteund door DualGauge-Bench.

DualGauge-Bench

Dit is een taal-agnostische benchmark bestaande uit 307 coding-taken.

Taakontwerp: Elke taak bestaat uit een specificatie in natuurlijke taal zonder code-snippets, functiesignaturen of taalspecifieke beperkingen.
Gepaarde Testing: Elke specificatie is gekoppeld aan twee testsuites afgeleid van dezelfde prompt:
- Functionele Tests: Gestuurd door boundary value analysis en equivalence-class partitioning om gedragsmatige correctheid te verifiëren.
- Security Tests: Gestuurd door OWASP- en CERT-principes om de afwezigheid van onveilige gedragingen te verifiëren (bijv. fouten in inputvalidatie, toegangscontrole-problemen).
Dekking: De benchmark beslaat zeven functionaliteitsdomeinen en 90 Common Weakness Enumeration (CWE) categorieën, waarbij zowel intraprocedurale als interprocedurale taken worden gedekt.
Constructie: Prompts werden gecureerd uit bestaande datasets (CodeGuard+, SecurityEval, Purple Llama CyberSecEval) en omgezet naar pure specificaties. Testsuites werden gecreëerd via een mens-LLM co-creatieproces, waarbij LLM's kandidaten voorstelden en menselijke beoordelaars deze valideerden en uitbreidden.

DualGauge Systeem

Het systeem werkt in vier fasen om de evaluatiepijplijn te automatiseren:

Sample Generatie: Het doel-LLM of de agent genereert $k$ code-kandidaten voor een gegeven specificatie.
Agentic Execution: Een door een LLM gestuurde executor voert de kandidaten uit in een geïsoleerde omgeving. Het classificeert fouten als milieu-, script- of code-problemen. Het herstelt milieu- en scriptproblemen (bijv. ontbrekende packages, aanroepfouten), maar wijzigt de kandide-code zelf niet. Dit zorgt ervoor dat het programma uitvoerbaar is zonder de logica van het model kunstmatig te corrigen.
LLM-gebaseerde Runtime Evaluatie:
- Functionele Oracle: Gebruikt exacte output-matching tegen verwachte outputs.
- Security Oracle: Gebruikt een LLM voor semantische beoordeling. Het analyseert de kandide-code, executie-outputs en coverage-traces tegen verwachte veiligheidsgedragingen. Als de code onbekende libraries gebruikt, haalt een resolver-model met web-zoekcapaciteiten documentatie op om de evaluatie te ondersteunen. Deze stap bepaalt of de code een werkelijke verdediging heeft geïmplementeerd in plaats van slechts per ongeluk te falen.
Resultaat Aggregatie: Berekent metrieken inclusief de functionele pass rate ($PR$), de secure pass rate ($SPR$) en de gezamenlijke metriek secure-pass@k (de waarschijnlijkheid dat een enkele sample zowel functioneel correct als veilig is).

Belangrijkste Resultaten

De auteurs evalueerden 10 representatieve LLM's (inclusief GPT-5, Claude Opus/Sonnet, Llama, Qwen en de Gemma-families) over Python, C++ en JavaScript, evenals 3 agentic coding-systemen (Codex, OpenHands, Claude Code).

1. Functionele Correctheid Overschat Betrouwbaarheid

Zelfs de sterkste modellen bereikten een functionele pass rate van bijna 39% op Python-taken, maar de gezamenlijke security-functionaliteit succesrate (secure-pass@1) bleef in elke taal onder de 15%. Dit geeft aan dat functionele correctheid een slechte proxy is voor veilige code-generatie.

2. Factoren aan de Modelzijde Verbeteren Gezamenlijke Prestaties Niet Betrouwbaar

De studie onderzocht vier factoren: schaal, extended thinking, kwantisatie en instructie/code-specialisatie.

Schaal: Het vergroten van de modelgrootte verbeterde de functionele fluentie, maar de security-dekking vlakte af ruim voordat de grootste groottes werden bereikt.
Extended Thinking & Specialisatie: Deze factoren verschoven de functionele en security-metrieken verschillend afhankelijk van de modelfamilie en verbeterden de gezamenlijke metriek niet betrouwbaar.
Conclusie: Veilige-en-correcte code-generatie komt niet simpelweg voort uit sterkere coding-capaciteiten; het vereist de consistente toepassing van security-kennis over alle vereisten.

3. Agentic Systemen Bieden Geen Voordeel

Iteratieve scaffolding door coding agents (Codex, OpenHands, Claude Code) bood geen voordeel ten opzichte van directe generatie voor specification-only taken.

Mechanisme van Falen: Agents besteedden veel energie aan repository-georiënteerde overhead (bijv. mappenlijsten, zoeken naar config-bestanden) die geen signaal opleverde in een lege workspace.
Feedback Loop: Agents vertrouwden vaak op zelf gegenereerde tests in plaats van ground-truth benchmarks. Partiële verdedigingen die de interne checks van de agent passeerden maar faalden voor de security-tests van de benchmark, werden niet herzien. Bijgevolg erfden agents dezelfde faalmodi als directe generatie zonder de coverage gap te dichten.

4. Faalmodi

Functionele Fouten: Geconcentreerd bij de output-contract grens (bijv. verkeerde JSON-structuur, incorrecte CLI versus service), niet bij algoritmische fouten.
Security Fouten: Gekenmerkt door partiële verdedigingen. Modellen implementeerden vaak guards (regex, type checks) die redelijk leken, maar faalden om de specifieke attack vector te dekken of werden toegepast op het verkeerde abstractieniveau.
Gezamenlijke Gap: Een programma kon functionele tests passeren terwijl het onveilig was, of sommige security-tests passeren terwijl het andere faalde. Alleen gezamenlijke benchmarking legde deze "stille" fouten betrouwbaar bloot.

Significantie en Claims

Het artikel claimt de eerste volledig geautomatiseerde framework te presenteren voor de gezamenlijke evaluatie van security en functionaliteit in specification-only code-generatie. De significantie ligt in:

Het Blootleggen van de Gap: Het aantonen dat huidige state-of-the-art modellen en agents moeite hebben om correctheid en veiligheid simultaan te bevredigen, waarbij de gezamenlijke succesrates kritiek laag blijven (<15%).
Methodologische Verschuiving: Argumenteren dat security-evaluatie semantische redenering over executie-traces vereist in plaats van output-matching, en dat benchmarks functionele en security-tests voor dezelfde specificatie moeten koppelen.
Beperkingen van Agents: Laten zien dat multi-turn verfijning en tool-gebruik nog niet automatisch de kernuitdaging overwinnen van het produceren van veilige code wanneer er geen bestaande codebase of test-runner beschikbaar is om de agent te begeleiden.
Benchmark Standaard: Het bieden van een taal-agnostische, herbruikbare benchmark (DualGauge-Bench) die verder gaat dan code-aanvulling om de fundamentele bekwaamheid van modellen te testen om natuurlijke taal-intentie te vertalen naar veilige, correcte code.

De auteurs concluderen dat veilige code-generatie de consistente toepassing van security-kennis vereist over de volledige ruimte van vereisten, een capaciteit die huidige modellen en agents nog niet beheersen. Zij benadrukken dat hun resultaten schaalbare benchmark-schattingen zijn en dat menselijke security-review noodzakelijk blijft.