Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation

Each language version is independently generated for its own context, not a direct translation.

Waarom AI-patchwerk faalt: Een verhaal over slimme maar onzorgvuldige monteurs

Stel je voor dat je een zeer slimme, maar nog jonge monteur hebt die je computerprogramma's moet repareren. Deze monteur is een LLM (een groot taalmodel, zoals een supergeavanceerde chatbot). Hij heeft duizenden handleidingen gelezen en kan perfect zinnen vormen. Maar als het gaat om het oplossen van veiligheidslekken (zoals een open raam waar inbrekers door kunnen klimmen), gaat het vaak mis.

Deze studie van Amir Al-Maamari kijkt naar 319 pogingen van zo'n AI-monteur om 64 verschillende veiligheidsproblemen in Java-code te fixen. Hier is wat ze ontdekten, vertaald naar alledaags taalgebruik:

1. De "Schijnveilige" Valstrik

De grootste verrassing is dat de monteur vaak perfect lijkt te werken, maar eigenlijk niets oplost.

Het probleem: De AI schrijft code die er grammaticaal perfect uitziet (het compileert) en waar de standaardtests geen fout in vinden. Het programma doet precies wat het moet doen.
De valstrik: De inbrekerdeur staat nog steeds open. De AI heeft het raam dichtgedaan, maar de sleutel hangt nog steeds onder de mat.
De statistiek: Van de 319 pogingen lukte het maar aan 25% om het lek écht te dichten én het programma goed te houden. Bij 51% van de pogingen was het programma zelfs niet veiliger én werkte het niet meer goed.

2. De "Goede Intenties, Foute Strategie"

Waarom lukt het niet? Het is niet omdat de AI de taal niet kent. Het is een misverstand over de betekenis.

Analogie: Stel je voor dat iemand een lek in een boot heeft. De AI denkt: "Ah, water komt binnen, ik ga de boot vullen met meer water om het gewicht te verdelen!" De boot zinkt niet direct (het werkt nog), maar hij zinkt wel langzaam.
De AI begrijpt de logica van de code, maar niet de intentie van de beveiliging. Ze passen de verkeerde oplossing toe op het juiste probleem. Ze zeggen: "Ik heb het raam dichtgedaan," terwijl ze eigenlijk de muur hebben gesloopt.

3. De Twee Werelden: Veiligheid vs. Functie

De studie introduceerde een nieuwe score, de Security Repair Score (SRS), om te meten hoe goed het gaat.

Functie (Doe wat het moet doen): De AI is hier heel goed in (score: 0,83). Hij breekt zelden iets dat al werkte.
Veiligheid (Maak het onkraakbaar): Hier faalt hij dramatisch (score: 0,25).
Het gevaar: De meest gevaarlijke fouten zijn die waarbij het programma perfect werkt, maar geen enkele beveiliging heeft. Dit zijn de "sluipmoordenaars". Ze gaan door de standaardtests (de CI/CD-pijplijn) en worden in productie gezet, terwijl hackers er zo in kunnen.

4. Het "Alles-of-Niets" Fenomeen

Je zou denken dat AI soms een beetje beter wordt als je het een beetje helpt. Maar de studie toont een twee-pieken patroon:

Of de AI lost het probleem perfect op.
Of hij faalt volledig (of maakt het erger).
Er zijn bijna geen "bijna-geslaagde" pogingen. Het is alsof de AI ofwel de sleutel heeft, ofwel helemaal niet. Kleine aanpassingen in de instructies helpen vaak niet, omdat het probleem niet ligt bij de details, maar bij het fundamentele inzicht.

5. Niet alle lekkages zijn even lastig

Sommige problemen zijn voor de AI makkelijker dan andere:

Makkelijk (45% succes): Problemen zoals een "oneindige lus" (een programma dat blijft hangen). Dit is mechanisch: "Stop de lus." De AI kan dat.
Onmogelijk (0% succes): Problemen zoals "invoer validatie" (controleer of wat de gebruiker typt veilig is). Dit vereist inzicht in de wereld: "Is deze e-mailadres echt een e-mailadres?" De AI weet niet wat "echt" is in deze context.

Wat betekent dit voor ons?

Vertrouw niet blindelings: Je kunt AI niet zomaar laten repareren aan beveiliging en hopen dat het goed komt. Het is alsof je een kind de auto laat repareren omdat het de handleiding kent; het ziet er misschien netjes uit, maar de remmen werken misschien niet.
Specifieke controle nodig: Vooral bij gevoelige onderwerpen (zoals wachtwoorden of toegang tot bestanden) moet een mens de code grondig controleren. De AI is hier het slechtst in.
Geen trade-off: Het goede nieuws is dat het veilig maken van code niet betekent dat je de functionaliteit moet opofferen. De AI faalt niet omdat hij moet kiezen, maar omdat hij het veiligheidsprobleem gewoon niet begrijpt.

Kortom: De AI is een briljante schrijver, maar nog geen ervaren beveiligingsexpert. Hij schrijft mooie verhalen, maar mist vaak de diepere betekenis van veiligheid.

Each language version is independently generated for its own context, not a direct translation.

Hier is een gedetailleerde technische samenvatting van het artikel "Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation" in het Nederlands.

Probleemstelling

Grote Taalmodellen (LLMs) tonen veelbelovende resultaten bij geautomatiseerde programmareparatie (APR) voor functionele bugs (bijv. in Defects4J of SWE-bench). Echter, hun effectiviteit bij het oplossen van veiligheidskwetsbaarheden is slecht gekarakteriseerd. Er bestaat een fundamentele spanning tussen functionaliteit en beveiliging:

Bestaande test suites verifiëren verwacht gedrag, maar verdedigen niet tegen adversariale invoer.
Een patch die alle tests doorstaat, kan het systeem toch kwetsbaar laten.
Recent onderzoek toont aan dat LLM-agenten kwetsbaarheden bijna negen keer vaker introduceren dan menselijke ontwikkelaars, en dat beveiligingsverharding vaak functionaliteit vernietigt.

De kernvraag is: Waarom falen LLMs bij het genereren van beveiligingspatches, en hoe kunnen we gedeeltelijk succes kwantificeren?

Methodologie

De studie analyseert 319 door LLMs gegenereerde patches voor 64 Java-kwetsbaarheden uit de Vul4J-benchmark. De experimentele opzet omvat:

LLM en Prompting:
- Gebruik van Gemini 2.0 Flash (in de tekst ook verwezen naar 3.0 Flash in de setup, maar de abstract noemt 2.0; de studie gebruikt een zero-shot prompt zonder gedetailleerde instructies om het intrinsieke veiligheidskennis van het model te testen).
- Er zijn 5 patches gegenereerd per kwetsbaarheid (temperatuur 0.7), wat resulteert in 320 patches (waarvan 319 na filtering).
Tri-As Evaluatie (Drie Assen):
Elke patch wordt getest op drie niveaus:
- Compilatie: Werkt de code (Maven/Gradle)?
- Beveiliging: Slagen de Proof-of-Vulnerability (PoV) tests (exploit-code) en Semgrep (statische analyse)?
- Functionaliteit: Slagen de volledige ontwikkelaarstest suites?
Metingen en Metriek:
- Security Repair Score (SRS): Een nieuwe continue metriek om gedeeltelijk succes te meten.
  - Formule: $SRS = C \times (0.5 \times S_{score} + 0.5 \times F_{score})$
  - Waarbij $C$ de compilatie is, $S_{score}$ gebaseerd is op PoV en Semgrep, en $F_{score}$ op het percentage geslaagde tests.
- Correlatieanalyse: Gebruik van Pearson en Spearman correlaties om te bepalen of kenmerken zoals complexiteit (Cyclomatic Complexity, LOC) of de grootte van de menselijke patch correleren met reparatiedifficultie.

Belangrijkste Bijdragen

Foutentaxonomie: Een classificatie van hoe LLM-patches falen (niet alleen "faalt", maar waarom).
Security Repair Score (SRS): Een metriek die het "grijze gebied" tussen volledig succes en volledig falen kwantificeert.
Identificatie van moeilijkheidsvoorspellers: Analyse van welke kwetsbaarheidstypen (CWE) en codekenmerken het repareren bemoeilijken.
Praktische richtlijnen: Actiepunten voor ontwikkelaars en onderzoekers op basis van de bevindingen.

Resultaten

1. Hoe falen patches? (RQ1)

Alleen 24,8% van de patches is volledig correct (compilatie, beveiliging en functionaliteit).
51,4% faalt zowel op beveiliging als functionaliteit.
Dominant falen: De meest voorkomende fout is semantisch misverstand. LLMs genereren syntactisch correcte code (86,8% compilatiekans), maar passen de verkeerde reparatiestrategie toe.
Gevaarlijkste categorie: 10,3% van de patches is functioneel correct maar onveilig. Deze patches gaan door CI/CD-pipelines heen maar laten het systeem kwetsbaar. Dit komt disproportioneel vaak voor bij toegangscontrole (CWE-264).

2. Gedeeltelijk succes (RQ2)

Asymmetrie: LLMs behouden functionaliteit uitstekend (gemiddelde Functionaliteit Score: 0,832) maar worstelen met beveiliging (gemiddelde Beveiliging Score: 0,251).
Bimodale verdeling: De SRS-scores tonen twee duidelijke clusters:
- Perfecte patches (SRS ≈ 1,0).
- Patches die functioneel zijn maar onveilig (SRS ≈ 0,5).
Geen "near-misses": Slechts 0,3% van de patches valt in het "bijna-succes" bereik. Dit suggereert dat LLM-beveiligingsreparatie een "alles-of-niets" vaardigheid is; kleine aanpassingen aan prompts helpen waarschijnlijk niet bij gedeeltelijk gefaalde patches.

3. Voorspellers van moeilijkheid (RQ3)

Kwetsbaarheidstype is cruciaal: Het type kwetsbaarheid (CWE) voorspelt de moeilijkheidsgraad sterk.
- 0% succes: Invoervalidatie (CWE-20). LLMs missen domeinspecifieke kennis over wat geldige invoer is.
- 45% succes: Oneindige lussen (CWE-835). Dit is meer "mechanisch" en vereist minder semantisch inzicht.
Patchgrootte: Er is een significante negatieve correlatie ( $\rho = -0,331$ ) tussen de grootte van de menselijke patch en het succes van de LLM. Grotere patches zijn moeilijker.
Complexiteit: Traditionele complexiteitsmetrieken (LOC, cyclomatic complexity) correleren niet met moeilijkheid. Het probleem ligt in het begrijpen van wat er moet veranderen (semantiek), niet in het navigeren door complexe code (structuur).

Betekenis en Implicaties

Voor Praktici:
- LLM-genereren patches vereisen rigoureuze validatie voordat ze worden ingezet. Standaard CI/CD-tests zijn onvoldoende; specifieke beveiligingstests (PoV) zijn essentieel.
- Er is een specifiek risico bij invoervalidatie en toegangscontrole; deze moeten door mensen worden gecontroleerd.
- Iteratief prompten bij gefaalde patches is waarschijnlijk zinloos gezien het gebrek aan "near-miss" gevallen.
Voor Onderzoekers:
- De kernbeperking is semantisch begrip, niet codegeneratie. Toekomstig werk moet focussen op het bieden van context-specifieke informatie (exploit-beschrijvingen, CWE-remediatiepatronen).
- CWE-specifieke routing is nodig: verschillende kwetsbaarheidstypen vereisen verschillende reparatiestrategieën (bijv. mechanische fixes vs. semantische redenering).
- De SRS-metriek biedt een betere manier om voortgang te meten dan alleen binair pass/fail.

Conclusie: LLMs zijn momenteel onbetrouwbaar voor geautomatiseerde beveiligingsreparatie zonder menselijke toezicht. Ze behouden functionaliteit goed, maar falen systematisch in het begrijpen van de onderliggende beveiligingslogica, wat leidt tot een dichotome uitkomst: ofwel volledig succes, ofwel fundamenteel verkeerde strategieën.