Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

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

🕵️‍♂️ De "Geheime Handtekening" van AI-Code

Stel je voor dat je een enorme fabriek hebt die automatisch gebouwen bouwt. In plaats van dat er duizenden verschillende architecten werken, gebruikt deze fabriek slechts een paar zeer specifieke, vaste blauwdrukken.

Dit is wat er gebeurt als AI (Large Language Models of LLM's) software schrijft. De AI is geweldig in het snel bouwen van apps, maar ze heeft een eigenaardigheid: ze herhaalt zich. Als ze een "Inlogknop" moet maken, gebruikt ze vaak exact dezelfde code-structuur, keer op keer. En als die structuur een foutje bevat, dan zit dat foutje in elke app die ze bouwt met die knop.

De onderzoekers van deze paper (uit Israël) hebben ontdekt dat ze deze fouten kunnen voorspellen zonder ooit de binnenkant van het gebouw te zien. Ze hebben een nieuw systeem bedacht dat ze FSTab noemen.

🗺️ De "Fouten-Atlas" (FSTab)

Stel je voor dat je een detective bent die een nieuw gebouw binnenstapt. Je mag niet naar de binnenkant kijken (geen toegang tot de broncode), maar je kunt wel naar de voordeur, de ramen en het bordje "Welkom" kijken.

Normaal gesproken zou je denken: "Ik weet niet wat er achter die deur zit."

Maar met FSTab (Feature–Security Table) kun je zeggen:

"Ah, ik zie een rode deur met een gouden handvat. Volgens mijn atlas betekent dat: 'Achter die deur zit een open raam waar een inbreker zo doorheen kan klimmen'."

Hoe werkt dit?

De Atlas maken: De onderzoekers lieten de AI duizenden apps bouwen. Ze keken welke "zichtbare dingen" (zoals een login-scherm of een knop om een bestand te uploaden) vaak gepaard gingen met welke "onzichtbare fouten" (zoals een zwak wachtwoord-systeem of een open database).
De Link: Ze maakten een lijstje: "Als je 'Login met wachtwoord' ziet, is de kans 90% dat er een specifiek type beveiligingslek in de achterkant zit."
De Aanval: Een hacker hoeft nu alleen maar naar de website te kijken, te zien welke knoppen er zijn, en op hun lijstje te kijken wat de waarschijnlijke fout is. Ze hoeven de code niet eens te zien!

🧠 Waarom gebeurt dit? (De "Recepten")

De onderzoekers noemen dit herhalende kwetsbaarheden.

Stel je voor dat een kok (de AI) een recept voor "Tomatensoep" heeft. Hij maakt die soep 100 keer. Elke keer gebruikt hij precies hetzelfde mes, precies dezelfde snijtechniek en precies hetzelfde potje.

Als hij per ongeluk een stukje glas in de soep doet, gebeurt dat elke keer als hij tomatensoep maakt.
Het maakt niet uit of hij de soep voor een restaurant in Parijs of voor een school in Amsterdam maakt. Het glas zit erin, omdat het recept (de AI's "stijl") hetzelfde is.

De paper laat zien dat AI's vaak "recepten" gebruiken die veiligheidsfouten bevatten. En omdat de AI zo consistent is, kun je die fouten voorspellen.

📊 De Resultaten: Het "Universum van Fouten"

De onderzoekers testten dit op de slimste AI's ter wereld (zoals GPT-5.2, Claude-4.5, etc.). Wat vonden ze?

Het werkt overal: Of je nu een webshop bouwt, een blog of een intern systeem voor een bedrijf. Als de AI een "Login"-functie maakt, zit er vaak een voorspelbare fout in.
De "Universale Kloof": Ze ontdekten iets verrassends. De fouten die een AI maakt in een webshop zijn vaak precies dezelfde als die in een sociale media-app. De AI heeft een "persoonlijkheid" van fouten. Als je weet hoe de AI faalt in één situatie, weet je hoe hij faalt in een andere.
Hoeveel succes? In sommige gevallen kon de "atlas" de hackers helpen om 94% van de mogelijke fouten te vinden, zelfs als ze de AI nooit eerder hadden gezien in dat specifieke vakgebied.

⚠️ Wat betekent dit voor ons?

Dit klinkt misschien eng, maar het is eigenlijk een belangrijke waarschuwing.

Voor ontwikkelaars: Je kunt niet zomaar vertrouwen op AI om veilig code te schrijven. Je moet de "recepten" controleren. Als je een login-scherm laat maken door AI, moet je extra goed kijken of er geen "glazen stukjes" in zitten.
Voor beveiliging: We moeten stoppen met alleen kijken naar de code die we hebben. We moeten ook kijken naar wie (of wat) de code heeft geschreven. Elke AI heeft zijn eigen "veiligheidsstijl".
De oplossing: De onderzoekers zeggen niet "gebruik geen AI". Ze zeggen: "Weet waar de valkuilen zitten." Met hun tool (FSTab) kunnen bedrijven proactief controleren: "O, we gebruiken AI-model X voor onze login. Weet je dat die model vaak een fout maakt bij wachtwoorden? Laten we dat eerst fixen voordat we online gaan."

🎯 Samenvatting in één zin

AI's schrijven code alsof ze een vast recept volgen; als dat recept een fout bevat, zit die fout in elke app die ze maken, en onderzoekers hebben nu een "spookkaart" gemaakt om die fouten te vinden zonder de code te hoeven zien.

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

Probleemstelling

Large Language Models (LLMs) worden steeds vaker gebruikt voor het genereren van code, wat leidt tot snelle prototyping en integratie in ontwikkelingswerkstromen. Echter, deze gegenereerde code bevat vaak kwetsbaarheden, zelfs als de functionaliteit correct lijkt. Het paper stelt dat LLMs, door hun probabilistische aard, neigen naar het hergebruiken van dezelfde "kanonieke sjablonen" voor veelvoorkomende functies (zoals inloggen of bestanden uploaden). Dit resulteert in voorspelbare, terugkerende kwetsbaarheidspatronen.

Het huidige beveiligingslandschap focust voornamelijk op post-hoc verdedigingen (zoals statische analyse van gegenereerde code). Een kritiek blind punt hierin is dat deze methoden elk programma geïsoleerd bekijken en niet modelleren hoe de onderliggende generatielogica van een specifiek model leidt tot systematische, voorspelbare fouten. Er ontbreekt een methode om, zonder toegang tot de backend-code, te voorspellen welke kwetsbaarheden aanwezig zijn op basis van waarneembare frontend-functies.

Methodologie: Feature–Security Table (FSTab)

De auteurs introduceren FSTab, een raamwerk dat twee hoofddoelen dient: een zwarte-doos-aanval (black-box attack) en een modelcentrische evaluatie.

1. De Aanval (Black-Box)

FSTab is een zoektabel die observable frontend-functies koppelt aan latente backend-kwetsbaarheden. De aanval verloopt in drie fasen:

Programma-reconnaissance: De aanval identificeert zichtbare UI-functies (bijv. "Reset Wachtwoord", "Bestand Uploaden") zonder toegang tot de broncode.
Feature Mapping: Deze waargenomen elementen worden gemapt naar een gestandaardiseerd schema van 59 frontend-functies.
Database Query: Op basis van de bekende bron-LLM (bijv. GPT-5.2, Claude-4.5) en de gemapte functies, queryt de aanval de FSTab-tabel. Deze tabel bevat de meest waarschijnlijke kwetsbaarheden die statistisch gekoppeld zijn aan die specifieke functies voor dat specifieke model.

Bouw van FSTab:

Er wordt een grote corpus gegenereerd door de doel-LLM.
Deze code wordt gelabeld met statische analyse-tools (CodeQL, Semgrep) om de "ground truth" van kwetsbaarheden te bepalen.
In plaats van ruwe frequenties te gebruiken, wordt Pointwise Mutual Information (PMI) toegepast om de associatie te scoren tussen een functie $f$ en een kwetsbaarheid $r$ . Dit filtert algemene fouten en isoleert model-specifieke patronen.
Een diversiteitsbevorderend algoritme selecteert de top-k kwetsbaarheden per functie om te voorkomen dat dezelfde algemene fouten aan alles worden gekoppeld.

2. Evaluatie Framework

Om de persistentie van kwetsbaarheden te meten, definiëren de auteurs vier metrics:

FVR (Feature Vulnerability Recurrence): Hoe vaak treedt dezelfde kwetsbaarheid op bij een specifieke frontend-functie?
RVP (Rephrasing Vulnerability Persistence): Blijven kwetsbaarheden bestaan als de prompt semantisch wordt herschreven?
DVR (Domain Vulnerability Recurrence): Herhalen zich kwetsbaarheden binnen een specifiek domein (bijv. e-commerce)?
CDT (Cross-Domain Transfer): Kunnen kwetsbaarheden die in één domein zijn geleerd, worden gebruikt om kwetsbaarheden in een ander domein te voorspellen?

Belangrijkste Bijdragen

Universele Black-Box Aanval: FSTab maakt het mogelijk om backend-kwetsbaarheden te voorspellen puur op basis van de modelidentiteit en zichtbare UI-functies, zonder broncode-inzicht.
Modelcentrisch Evaluatie Framework: Een nieuwe methode om modellen te vergelijken op basis van hoe consistent ze terugkerende zwakke patronen genereren, in plaats van alleen individuele fouten te tellen.
Empirische Karakterisering: Een uitgebreide analyse van zes state-of-the-art code-LLMs (waaronder GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro) over vijf verschillende applicatiedomeinen.

Resultaten

De experimenten tonen aan dat kwetsbaarheidspatronen sterk persistent en model-specifiek zijn:

Hoog Succespercentage: De aanval bereikte een Attack Success Rate (ASR) tot 94% en een Vulnerability Coverage van 93% op het "Internal Tools"-domein voor Claude-4.5 Opus, zelfs zonder toegang tot de backend-code.
Cross-Domain Transfer: Er is een sterke transfer van kwetsbaarheden tussen domeinen. Zelfs als het doel-domein volledig uit de trainingsdata is verwijderd, behoudt FSTab een hoge nauwkeurigheid. Dit suggereert dat de kwetsbaarheden inherent zijn aan het model en niet aan het specifieke domein.
Invloed van Prompt: Modellen met een hoge RVP (zoals Composer met 35,53%) vertonen zeer stabiele kwetsbaarheden, ongeacht hoe de prompt wordt herschreven. Modellen met lage RVP (zoals Grok) zijn gevoeliger voor variatie in de prompt, maar vertonen nog steeds voorspelbare patronen.
Universele Kloof (Universality Gap): De CDT-scores zijn over het algemeen hoger dan de DVR-scores. Dit betekent dat modellen hun kwetsbaarheden beter overdragen naar andere domeinen dan ze binnen hetzelfde domein herhalen, wat aantoont dat de patronen model-intrinsiek zijn.

Betekenis en Impact

Dit paper onthult een onderbelichte aanvalsoppervlakte in door LLM gegenereerde software: de voorspelbaarheid van kwetsbaarheden door model-bias.

Beveiligingsrisico: Aanvallers kunnen nu systematisch kwetsbaarheden prioriteren en exploiteren door alleen de frontend te inspecteren en de bron-LLM te kennen. Dit verlaagt de drempel voor grootschalige cyberaanvallen.
Defensieve Implicaties: De auteurs pleiten voor een verschuiving van puur code-analyse naar modelcentriske risicobeoordeling. Ontwikkelaars en auditors moeten rekening houden met de specifieke "veiligheidsvingerafdruk" van het gebruikte LLM.
Toekomstige Richtingen: Het paper suggereert dat mitigatie vereist is in de vorm van het verminderen van sjabloon-rigiditeit in modellen, het toevoegen van veiligheidsbewuste regressietests voor hoog-risico functies, en het ontwikkelen van benchmarks die persistentie meten in plaats van alleen incidentele fouten.

Samenvattend toont het onderzoek aan dat LLMs niet willekeurige fouten maken, maar systematische, reproduceerbare kwetsbaarheden genereren die als een "vingerafdruk" van het model kunnen worden gebruikt om de beveiliging van gegenereerde software te doorbreken.