🤖 machine learning

An Empirical Study of Security Calibration in Large Language Models for Code

Dit artikel presenteert de eerste grootschalige empirische studie die onthult dat grote taalmodellen een wijdverbreide overmoed vertonen in hun gegenereerde code, waarbij de functionele kalibratie consistent slechter is dan de beveiligingskalibratie, en dat hoewel kalibratiegestuurde reparatie en architecturale gating beperkte voordelen bieden, ze er vaak niet in slagen om hoog-betrouwbare kwetsbaarheden in realistische repository-niveau contexten te voorkomen.

Oorspronkelijke auteurs: Mohammed Latif Siddiq, Md. Nafiu Rahman, Joanna C. S. Santos

Gepubliceerd 2026-07-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Mohammed Latif Siddiq, Md. Nafiu Rahman, Joanna C. S. Santos

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 team hebt van zeer getalenteerde, maar licht overmoedige junior programmeurs. Je vraagt hen code te schrijven die de beveiliging van je digitale huis waarborgt. Ze schrijven de code en vertellen je vervolgens met een grote glimlach: "Ik weet voor 95% zeker dat dit veilig is!"

Dit artikel is als een realitycheck voor dat scenario. De onderzoekers vroegen zich af: Weten deze AI-programmeurs eigenlijk wanneer ze het fout hebben, of zeggen ze gewoon vol vertrouwen dat ze het goed hebben, zelfs als ze gevaarlijke fouten maken?

Hier is de uitsplitsing van hun bevindingen met behulp van eenvoudige analogieën:

1. Het probleem van de "Zelfverzekerde Fout"

De studie toonde aan dat deze AI-modellen lijden aan Vals Vertrouwen.

De Analogie: Stel je een weervoorspeller voor die zegt: "Er is 90% kans op zonneschijn," maar het regent elke keer dat hij dit zegt.
De Bevinding: Wanneer de AI code genereert met een kwetsbaarheid (zoals een achterdeur voor hackers), beweert de AI vaak met 90% of 95% zekerheid dat de code veilig is. In werkelijkheid is de code vaak onveilig. De AI is als een bestuurder die door een rood licht rijdt terwijl hij zelfverzekerd volhoudt: "Ik weet zeker dat ik het haal."

2. De verrassing van "Veilig versus Werkend"

Een van de meest interessante ontdekkingen ging over waar de AI over in de war raakt.

De Analogie: Denk aan een chef-kok.
- Functionele Correctheid: Smaakt het gerecht goed en volgt het het recept?
- Beveiliging: Is de keuken vrij van gif?
De Bevinding: De AI is eigenlijk beter in het weten of zijn "gif" (beveiligingsfouten) aanwezig is, dan in het weten of het "gerecht" (de functionele code) werkt.
- De AI realiseert zich vaak niet dat zijn code kapot is (het werkt niet), maar is iets beter in het beseffen of hij per ongeluk "gif" in de code heeft achtergelaten.
- Waarom? De onderzoekers suggereren dat "werkende" code afhankelijk is van verborgen, complexe zaken (zoals specifieke softwareversies of verborgen instellingen) die de AI niet kan zien. Maar "beveiligingsfouten" zijn vaak zichtbare patronen (zoals het gebruik van een bekende gevaarlijke tool) die de AI makkelijker kan herkennen, ook al overschat hij zijn eigen vaardigheid nog steeds.

3. De "Solo-act" versus "Het Grote Orkest"

De onderzoekers testten de AI in twee verschillende omgevingen:

Omgeving A (Zelfvoorzienend): De AI vragen om een enkele, geïsoleerde functie te schrijven (zoals een solo pianospeler).
Omgeving B (Repository-niveau): De AI vragen om een bug te repareren in een enorm, echt softwareproject met duizenden bestanden en afhankelijkheden (zoals een heel orkest dat samen speelt).
De Bevinding: De zelfverzekerdheid van de AI stortte in in de "Grote Orkest"-omgeving.
- In de solo-setting was de AI overmoedig, maar enigszins beheersbaar.
- In de echte wereld werd de AI extreem overmoedig. De AI beweerde bijvoorbeeld 90% zeker te zijn dat zijn fix werkte, maar omdat hij het complexe web van andere bestanden niet begreep, maakte de fix het hele systeem kapot of liet de beveiligingslek open. De complexiteit van de echte wereld maakte de "zelfverzekerdheidsmeter" van de AI volkomen nutteloos.

4. Kunnen we de AI "repareren"?

De onderzoekers probeerden de eigen zelfverzekerdheid van de AI te gebruiken om zijn fouten te herstellen.

De Strategie: "Als de AI zegt dat hij slechts 40% zeker is, laten we hem dan opnieuw proberen."
Het Resultaat: Dit werkte niet goed.
- De Analogie: Het is alsoak je een verwarde bestuurder vraagt om "opnieuw te proberen" door een doolhof te navigeren. In plaats van het juiste pad te vinden, rijden ze vaak tegen een muur aan (waardoor de functionaliteit van de code breekt).
- De Specifieke Barrière: De studie vond dat sommige beveiligingslekken lijken op een gesloten deur die een specifieke sleutel nodig heeft (het vervangen van een gevaarlijke tool door een veilige). De AI is erg slecht in het wisselen van deze sleutels. Hij probeert eerder een "Niet betreden"-bordje op de deur te hangen (een waarschuwing toevoegen) in plaats van daadwerkelijk het slot te veranderen. Dit wordt een "Rigiditeitsbarrière" genoemd.

5. Hoe lossen we het vertrouwensprobleem op?

De onderzoekers testten een paar manieren om te voorkomen dat we de AI blindelings vertrouwen:

De "Poortwachter"-methode (Meest effectief): Vraag de AI niet eerst: "Is dit veilig?", maar vraag eerst: "Draait deze code daadwerkelijk?"
- Als de code niet draait, gooi deze dan onmiddellijk weg.
- Resultaat: Dit verminderde aanzienlijk hoe vaak de AI "zelfverzekerd fout" was over de beveiliging. Het is alsof je controleert of een auto een motor heeft voordat je de bestuurder vraagt of de remmen werken.
De "Voorbeeld"-methode (Minder effectief): De AI voorbeelden van goede code laten zien.
- Resultaat: De AI leerde het patroon van de "goede code", maar slaagde er vaak niet in om dit in het specifieke project te passen, waardoor het systeem in de proces brak.

De Kernboodschap

Het artikel concludeert dat we de "zelfverzekerdheidsscore" van de AI niet kunnen vertrouwen als een garantie voor veiligheid.

De AI is vaak overmoedig, vooral in complexe, echte projecten.
De zelfverzekerdheid van de AI is een slechte indicator voor de vraag of de code daadwerkelijk veilig is.
De beste aanpak is om de output van de AI te behandelen als een conceptversie die rigoureus getest moet worden (gecontroleerd op fouten en beveiligingsgebreken) door mensen of geautomatiseerde tools, in plaats van het simpelweg te accepteren omdat de AI zegt: "Ik weet zeker dat dit klopt."

Kortom: Laat je niet misleiden door het zelfvertrouwen van de AI. Zelfs als het zeker klinkt, kan het fout zijn.

Technische Samenvatting: Een Empirische Studie naar Beveiligingskalibratie in Large Language Models voor Code

1. Probleemstelling

Large Language Models (LLM's) worden steeds vaker geïntegreerd in workflows voor softwareontwikkeling voor taken zoals codegeneratie en het oplossen van bugs. De implementatie hiervan in beveiligingskritische contexten roept echter een fundamentele vraag op: weten modellen accuraat wanneer hun gegenereerde code onveilig is?

Hoewel bestaande benchmarks (bijv. HumanEval, MBPP, SWE-Bench) de functionele correctheid evalueren, negeren ze grotendeels beveiligingseigenschappen. Recente beveiligingsgeoriënteerde benchmarks beoordelen of code kwetsbaarheden bevat, maar falen in het meten of modellen in staat zijn om de beveiliging van hun eigen outputs te zelf-evalueren. Deze kloof leidt tot het False Trust-fenomeen (vals vertrouwen), waarbij modellen een hoge mate van vertrouwen toekennen aan kwetsbare code. Ontwikkelaars, die vertrouwen op deze vertrouwenssignalen, kunnen onveilige outputs zonder controle accepteren, waardoor kwetsbaarheden in productiesystemen terechtkomen.

Eerder werk heeft niet systematisch de beveiligingskalibratie gemeten — de afstemming tussen het door een model geuite vertrouwen in de beveiliging van zijn output en de werkelijke beveiligingsstatus van die output. Bovendien is het onbekend of de geobserveerde kalibratiepatronen in geïsoleerde, zelfstandige programma's generaliseren naar realistische, multi-file repository-contexten, of dat kalibratiesignalen effectief kunnen dienen als gids voor geautomatiseerde reparatie van kwetsbaarheden.

2. Methodologie

De auteurs presenteren de eerste grootschalige empirische studie naar beveiligingskalibratie, waarbij drie state-of-the-art modellen worden geëvalueerd: GPT-4o-mini, Gemini-2.0-Flash en Qwen3-Coder-Next. De studie maakt gebruik van een evaluatie in meerdere fasen over twee complementaire benchmarks en vier onderzoeksvragen (RQ's).

Datasets en Contexten

Zelfstandige Programma's (RQ1): Maakte gebruik van de SALLM-benchmark, bestaande uit 100 beveiligingskritische Python-taken. Elke taak biedt een enkele prompt met inputs, verwachte outputs en beveiligingseisen, geïsoleerd van externe afhankelijkheden.
Repository-niveau Contexten (RQ2): Maakte gebruik van de AICGSecEval-benchmark, met 125 prompts in vier talen (C, Java, PHP, Python) en 29 CWE's. Deze taken vereisen het genereren van patches binnen bestaande multi-file repositories, waarbij rekening moet worden gehouden met cross-file afhankelijkheden, build-configuraties en externe API's.

Experimentele Opzet

Modellen & Parameters: Elk model werd getest over zes temperatuurinstellingen (0.0 tot 1.0), waarbij 20 samples per taak werden gegenereerd.
Vertrouwensschatting: Vier methoden werden vergeleken:
1. Token-waarschijnlijkheidsaggregatie: Directe toegang tot logit-waarschijnlijkheden (voor GPT/Gemini).
2. Verbaal geuite vertrouwensgraad: Het model instrueren om een JSON te produceren met een vertrouwensscore (0–1) en redenering.
3. Sampling-gebaseerde consistentie: Het vertrouwen schatten als het fractie van de 20 samples dat verificatie doorstaat.
4. Self-consistency prompting: Chain-of-Thought (CoT) redenering vóór het rapporteren van vertrouwen.
Verificatie: Code werd uitgevoerd in geïsoleerde Docker-containers. Beveiligingslabels werden gedefinieerd als $y_{sec} = y_{func} \land \neg y_{vuln}$ , wat betekent dat de code alle functionele tests moet passeren én alle kwetsbaarheidsexploit-tests moet falen om als veilig te worden beschouwd.
Metrieken: Expected Calibration Error (ECE), Brier Score, Overconfidence Gap, en de False Trust (FT) rate (voorspellingen met een hoog vertrouwen die onveilig zijn).

Reparatie- en Mitigatiestrategieën (RQ3 & RQ4)

Kalibratie-gestuurde Reparatie: Een closed-loop systeem filterde samples met een lage gekalibreerde vertrouwensgraad ( $p_{sec} < 0.5$ ) voor iteratieve reparatie. De uitkomsten werden gestratificeerd naar type kwetsbaarheid: Sink Replacement (SR) (vereist wijzigingen in API's) en Constraint Enforcement (CE) (vereist validatielogica).
Mitigatie-experimenten:
1. Execution Gating: Het wegfilteren van functioneel incorrecte code voordat de beveiligingsvertrouwensgraad wordt opgevraagd.
2. Authorized-Breaking Repair: Expliciet toestemming geven aan modellen om backward compatibiliteit te verbreken (bijv. pickle vervangen door json) om SR-kwetsbaarheden te herstellen.
3. Few-Shot Prompting: Het verstrekken van veilige codevoorbeelden.
4. Few-Shot + CoT: Het toevoegen van redeneerstappen aan de few-shot voorbeelden.

3. Belangrijkste Resultaten

RQ1: Kalibratie in Zelfstandige Generatie

Systematische Overbevestiging: Alle modellen vertonen ernstige overbevestiging. GPT-4o-mini en Qwen3-Coder-Next laten een hoge ECE zien (respectievelijk 0.46–0.48 en 0.41–0.42), terwijl Gemini-2.0-Flash beter presteert maar nog steeds overbevestigd is (ECE 0.25–0.26).
False Trust: Bij een vertrouwensdrempel van 0.8 zijn de False Trust-rates alarmerend hoog (bijv. 33.5% voor GPT-4o-mini, 40.3% voor Qwen3-Coder-Next), wat aangeeft dat outputs met een hoog vertrouwen vaak onveilig zijn.
Functionele vs. Beveiligingskalibratie: Tegen intuïtie in is functionele kalibratie consequent slechter dan beveiligingskalibratie ( $\Delta ECE < 0$ ). Modellen zijn meer misgekalibreerd wat betreft functionele correctheid dan wat betreft beveiliging. Dit suggereert dat modellen beveiligingsuitkomsten betrouwbaarder inschatten dan functionele uitkomsten, mogelijk omdat functionele correctheid afhangt van complexe, verborgen executiegedragingen.
Vertrouwensmethoden: Token-waarschijnlijkheidsaggregatie levert een slechte kalibratie op (ECE $\approx$ 0.80). Sampling-gebaseerde consistentie vertoont een ECE van bijna nul, maar mist discriminatie per sample. Verbaal geuite vertrouwensgraad is het meest praktische signaal voor downstream analyse.

RQ2: Degradatie op Repository-niveau

Kalibratie-instorting: De overgang van zelfstandige taken naar repository-niveau contexten zorgt voor een significante verslechtering van de kalibratie. De ECE verdrievoudigt of verviervoudigt ruwweg (bijv. GPT-4o-mini ECE stijgt van 0.41 naar 0.70).
Surge in False Trust: De False Trust-rates springen van ~17% in zelfstandige taken naar >80% in repository-settings.
Decompositie: De degradatie wordt gedreven door twee factoren: build fragiliteit (code die niet compileert/draait) en cross-file complexiteit. Hoewel build fragiliteit een groot deel van de fout verklaart (tot 82% voor GPT), blijft echte cross-file complexiteit een significante factor, zelfs bij succesvol gebouwde patches.

RQ3: Kalibratie-gestuurde Reparatie

Beperkte Effectiviteit: Het gebruik van kalibratiesignalen om reparatie te sturen levert minimale beveiligingsverbeteringen op en verslechtert vaak de functionaliteit.
Structurele Barrières: Sink Replacement (SR) kwetsbaarheden (die API-swaps vereisen) hebben een reparatiesuccespercentage van 0% over alle modellen heen. Modellen slagen er niet in om onveilige API's te vervangen, maar behouden in plaats daarvan de kwetsbaarheid of introduceren oppervlakkige fixes.
Functionele Regressies: Reparatiepogingen breken frequent de functionele correctheid (breakage rates >60%), wat leidt tot een algehele afname van de veiligheid. Kalibratie fungeert als een risico-stratificatiesignaal, maar kan geen effectieve geautomatiseerde reparatie voor structurele kwetsbaarheden aansturen.

RQ4: Mitigatiestrategieën

Execution Gating: De meest effectieve mitigatie. Het wegfilteren van functioneel incorrecte code voordat er om beveiligingsvertrouwen wordt gevraagd, vermindert de ECE met 31–39% over de modellen heen. Dit gaat echter gepaard met een hoge kostprijs van het verwerpen van 46–86% van de samples.
Authorized-Breaking Repair: Het expliciet autoriseren van API-wijzigingen verbetert de verwijdering van kwetsbaarheden voor GPT en Gemini (35–42%), maar resulteert nog steeds in een hoge functionele breakage en een lage strikte succesratio.
Prompting Technieken: Few-shot prompting verwijdert ~61–65% van de kwetsbaarheden, maar slaagt zelden in een strikte harness-evaluatie vanwege structurele integratiemismatches. Het toevoegen van Chain-of-Thought (CoT) redenering verslechtert de kalibratie en brengt de strikte succesratio terug naar 0%.

4. Belangrijkste Bijdragen

Eerste Grootschalige Studie: De eerste empirische onderzoek naar beveiligingskalibratie in door LLM gegenereerde code, bes覆盖nd over 36.000 samples over drie modellen, zes temperaturen en twee verschillende ontwikkelingscontexten.
Analyse van Kalibratiedegradatie: Kwantificering van de zware kalibratiepenalty die optreedt bij de overgang van geïsoleerde functies naar realistische repository-niveau contexten, wat de risico's van cross-file afhankelijkheden benadrukt.
Beperkingen van Reparatie: Demonstratie dat kalibratie-gestuurde reparatie onbetrouwbaar is, met name voor Sink Replacement kwetsbaarheden, vanwege een "rigiditeitsbarrière" waarbij modellen niet in staat zijn tot de noodzakelijke structurele transformaties.
Evaluatie van Mitigatie: Systematische evaluatie van architecturale (execution gating) en prompt-niveau interventies, waarbij vastgesteld is dat execution gating de meest effectieve strategie is voor het verminderen van False Trust, zij het met hoge afwijzingskosten.

5. Betekenis en Claims

Het paper betoogt dat kalibratie, en niet alleen nauwkeurigheid, een centraal evaluatiecriterium moet zijn voor LLM's in beveiligingskritische omgevingen. De bevindingen dagen de aanname uit dat "beveiliging moeilijker is" voor LLM's; in plaats daarvan onthult de studie dat functionele kalibratie slechter is dan beveiligingskalibratie, wat suggereert dat miskalibratie grotendeels voortkomt uit verborgen runtime-beperkingen (executie-broosheid) in plaats van een gebrek aan beveiligingskennis.

De auteurs claimen dat:

Zelfgerapporteerd vertrouwen onbetrouwbaar is: Outputs met een hoog vertrouwen zijn frequent onveilig, wat een systemisch risico op False Trust creëert.
Context ertoe doet: Benchmarks gebaseerd op zelfstandige programma's onderschatten de implementatierisico's aanzienlijk, aangezien de kalibratie drastisch verslechtert in repository-niveau contexten.
Reparatie geen wondermiddel is: Kalibratiesignalen kunnen samples prioriteren voor menselijke beoordeling, maar kunnen momenteel geen betrouwbare geautomatiseerde reparatie aandrijven voor structurele kwetsbaarheden.
Praktijkrichtlijn: Beveiligingsbeoordeling moet pas plaatsvinden na functionele testen (execution gating), en vertrouwenssignalen voor beveiliging en functionaliteit moeten apart worden opgevraagd om contaminatie door executie-onzekerheid te voorkomen.

De studie concludeert dat hoewel LLM's enige bekwaamheid tonen in het zelf inschatten van beveiliging, hun overbevestiging en onvermogen om structurele reparaties uit te voeren, menselijk toezicht noodzakelijk maken, vooral in complexe, multi-file ontwikkelomgevingen.