Technische Samenvatting: AUTOBAXBUILDER

Probleemstelling

Naarmate Large Language Models (LLM's) steeds vaker worden geïntegreerd in software-engineering, is een betrouwbare beoordeling van de correctheid en beveiliging van door LLM's gegenereerde code cruciaal geworden. Eerdere onderzoeken wijzen erop dat LLM's vaak code met beveiligingskwetsbaarheden genereren, waarbij ze beveiliging vaak opofferen ten gunste van functionele correctheid. Bestaande evaluatiekaders lijden onder drie primaire beperkingen:

1. Data-verontreiniging: Handmatig ontworpen benchmarks lekken onvermijdelijk in de trainingsdata van toekomstige modellen, wat de validiteit van de evaluatie ondermijnt.
2. Schaalbaarheid en uitbreidbaarheid: Het creëren van nieuwe benchmarks vereist aanzienlijke menselijke inspanning om scenario's te ontwerpen, functionele tests te schrijven en beveiligingsexploits te ontwikkelen, waardoor het moeilijk is om gelijke tred te houden met snel verbeterende modellen.
3. Moeilijkheid om te schalen: Benchmarks moeten continu in moeilijkheidsgraad toenemen om capabelere LLM's uit te dagen, een taak die voor menselijke experts veel middelen vergt.

Huidige benchmarks beoordelen correctheid en beveiliging vaak op gescheiden taken of richten zich uitsluitend op generatie op functieniveau, waardoor ze de complexiteit van volledige applicatie-backends niet vastleggen. Hoewel de BAXBENCH-benchmark dit aanpakte door end-to-end webapplicatie-backends te evalueren, berustte de creatie ervan zwaar op handmatige menselijke inspanning, wat zijn levensduur en schaalbaarheid beperkte.

Methodologie: AUTOBAXBUILDER

De auteurs stellen AUTOBAXBUILDER voor, een geautomatiseerde, agentische pijplijn die de creatie van code-beveiligingsbenchmarktaken van scratch bootstrapst. Het systeem maakt gebruik van de code-begrijpingscapaciteiten van LLM's, gecombineerd met robuuste uitvoeringsgebaseerde betrouwbaarheidscontroles, om scenario-specificaties, functionele tests en end-to-end beveiligingsexploits te genereren zonder menselijke tussenkomst.

De pijplijn werkt in drie iteratieve verfijningstappen, georkestreerd door een centrale LLM (de "Orchestrator") en gevalideerd tegen referentieoplossingen gegenereerd door "Solution LLM's":

1. Scenariovoorstel: De orchestrator genereert een nieuw backend-service-specificatie (in OpenAPI-formaat) die is ontworpen om een duidelijk aanvalsoppervlak bloot te leggen. Het zorgt voor nieuwheid door te controleren tegen bestaande scenario-titels. Solution LLM's genereren vervolgens initiële referentie-implementaties.
2. Generatie van functionele tests: De orchestrator extrahert functionele eisen en construeert functionele tests. Om correctheid te waarborgen, hanteert de pijplijn een tweefasige verfijningslus:
   • Oplossingen verfijnen: Falende referentieoplossingen worden gecorrigeerd op basis van uitvoeringslogs, zonder dat de orchestrator de testcode ziet om overfitting te voorkomen.
   • Tests verfijnen: De orchestrator analyseert de relatie tussen testcode, oplossingcode en uitvoeringslogs om te bepalen of een falen voortkomt uit een gebrekkige test of een gebrekkige oplossing. Het itereren totdat een wereldwijd consensus is bereikt, waarbij ten minste één referentieoplossing alle tests doorstaat.
3. Generatie van beveiligingsexploits: De orchestrator identificeert potentiële kwetsbaarheden (CWE's) in het scenario en de referentieoplossingen. Voor elke doelwitkwetsbaarheid genereert het een exploit en valideert deze met een contrastieve aanpak:
   • De exploit wordt uitgevoerd op een referentieoplossing.
   • Als het resultaat correct is (bijvoorbeeld een kwetsbare oplossing wordt gemarkeerd), genereert de orchestrator een "contrastieve" oplossing door de kwetsbaarheid te patchen of in te brengen, uitsluitend gebaseerd op de natuurlijke taalbeschrijving van de kwetsbaarheid (niet op de exploit-logica).
   • De exploit wordt alleen geaccepteerd als deze correct onderscheid maakt tussen de veilige en onveilige versies van de oplossing. Dit proces itereren totdat een nauwkeurig paar veilige/onveilige oplossingen is gevonden.

De pijplijn bevat veiligheidsmechanismen zoals YAML-verificatie voor OpenAPI-specificaties, Python-compilatiecontroles voor code en zelfkritiekmechanismen om om te gaan met LLM-fouten.

Belangrijkste Bijdragen

1. Geautomatiseerde benchmarkconstructie: Een robuuste methode om volledig nieuwe benchmarks te construeren volgens de ontwerpprincipes van BAXBENCH met minimale menselijke tussenkomst.
2. Validatie tegen expert-baselines: Demonstratie dat de methode door experts geschreven functionele tests en exploits op dezelfde taken reproduceert of overtreft, waardoor de door BAXBENCH gerapporteerde beveiligingsbovengrens effectief wordt verstrakt.
3. AUTOBAXBENCH: De constructie en release van een nieuwe benchmark bestaande uit 40 nieuwe scenario's, verdeeld in drie subsets van toenemende moeilijkheidsgraad (Makkelijk, Gemiddeld, Moeilijk), waarmee het aantal beschikbare backend-scenario's voor code-beveiligingsbenchmarking meer dan verdubbelt.

Experimentele Resultaten

De auteurs evalueerden de pijplijn en de resulterende AUTOBAXBENCH-benchmark met een breed scala aan state-of-the-art LLM's (waaronder GPT-5, Claude 4.5 Sonnet, Gemini 3 Pro en diverse open-weight modellen).

• Pijplijnvalidatie: Toegepast op bestaande BAXBENCH-scenario's, toonden de door AUTOBAXBUILDER gegenereerde tests en exploits een hoge overeenkomst met handmatig geschreven versies. Specifiek kwamen functionele tests overeen bij 80,9% van de oplossingen. Beveiligingsexploits gegenereerd door de pijplijn markeerden meer gevallen als onveilig dan de originele handmatig geschreven exploits, toegeschreven aan de ontdekking van extra CWE's en aanvalsvarianten. Handmatige audit van 71 gegenereerde exploits vond slechts één onjuiste exploit.
• Benchmarkprestaties: Op AUTOBAXBENCH behaalde zelfs het sterkst geëvalueerde model (Claude 4.5 Sonnet) slechts een algehele sec_pass@1 (ratio van veilige en correcte oplossingen) van 36%. Op de "Moeilijk"-split daalde dit naar 25%. De kloof tussen pass@1 (functionele correctheid) en sec_pass@1 benadrukt dat veel functioneel correcte implementaties nog steeds exploiteerbaar blijven.
• Efficiëntie: De pijplijn genereert nieuwe taken in minder dan 2 uur met een API-kostprijs van minder dan $4 per taak. Inclusief handmatige verificatie reduceert dit de menselijke inspanning met een factor 12 ten opzichte van handmatige constructie.
• Robuustheid: Ablatiestudies met disjuncte sets modellen voor constructie toonden een hoge rangcorrelatie (Spearman $\rho > 0,9$) in modelprestaties, wat aangeeft dat de benchmark niet bevooroordeeld is ten opzichte van de modellen die zijn gebruikt om deze te genereren.

Betekenis en Claims

Het paper claimt dat AUTOBAXBUILDER de kritieke uitdaging van benchmarkverontreiniging en schaalbaarheid in LLM-beveiligingsevaluatie aanpakt. Door de generatie van onverontreinigde, hoogwaardige benchmarks te automatiseren, maakt het kader een langetermijn, betrouwbare beoordeling van de veilige codeercapaciteiten van LLM's mogelijk.

De auteurs benadrukken dat hun methode een sound bovengrens voor beveiliging biedt door uitvoeringsgebaseerde exploits te gebruiken in plaats van statische analyse, die vatbaar is voor vals-positieven en vals-negatieven. Zij stellen dat het kader "toekomstbestendig" is, in staat om steeds moeilijkere taken te genereren naarmate de modelcapaciteiten verbeteren, en de complexiteit van ingezette backend-API's benadert. Het werk concludeert dat hoewel LLM's vooruitgang hebben geboekt in functionele codegeneratie, er een aanzienlijke kloof blijft in hun vermogen om betrouwbaar veilige code te genereren, een kloof die AUTOBAXBENCH effectief blootlegt.