🤖 AI

Secure Code Generation at Scale with Reflexion

Dit artikel evalueert de effectiviteit van reflexion prompting bij het verbeteren van de beveiliging van door vijf instructie-afgestemde grote taalmodellen gegenereerde code, waarbij wordt vastgesteld dat terwijl zero-shot baselines in 25-33% van de gevallen onveilige code produceren, een reflexionproces van drie ronden de beveiligingsmetrieken aanzienlijk verbetert, waarbij de meest substantiële winst optreedt in de eerste ronde.

Oorspronkelijke auteurs: Arup Datta, Ahmed Aljohani, Hyunsook Do

Gepubliceerd 2026-06-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Arup Datta, Ahmed Aljohani, Hyunsook Do

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 ingehuurd van zeer getalenteerde, rap pratende junior programmeurs (de AI-modellen) om code te schrijven voor je software. Je geeft ze een eenvoudige instructie, zoals "Bouw een beveiligde inlogpagina," en ze typen razendsnel door.

Dit artikel stelt een simpele maar cruciale vraag: Alleen omdat de code werkt, is het dan ook daadwerkelijk veilig? En nog belangrijker: Als we tegen hen zeggen: "Hé, je hebt een fout gemaakt, probeer het opnieuw," kunnen ze het dan oplossen?

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

1. Het "Eerste Concept"-probleem

De onderzoekers ontdekten dat wanneer deze AI-modellen voor het eerst code schrijven (wat "zero-shot" wordt genoemd), het is alsof een student een toets maakt zonder te hebben geleerd.

Het resultaat: Ongeveer 25% tot 33% van de geschreven code bevat direct beveiligingslekken. Het is alsof je een blauwdruk van een huis inlevert waarbij de voordeur geen slot heeft, of de ramen van papier zijn gemaakt.
De analogie: Denk hierbij aan een chef die geweldig is in het maken van een heerlijke taart, maar steeds vergeet een deksel op de pot met gif te doen die hij naast de suiker heeft staan. De taart smaakt prima (de code werkt), maar het is gevaarlijk om te eten (de code is onveilig).

2. De "Reflexion"-lus (De Tweede Kans)

De onderzoekers lieten de chefs niet zomaar de taart serveren. Ze introduceerden een proces genaamd Reflexion.

Hoe het werkt: Nadat de AI de code heeft geschreven, controleert een beveiligingsscanner (een robot-inspecteur) deze en zegt: "Je hebt de achterdeur open laten staan," of "Je hebt een zwak slot gebruikt." De AI leest vervolgens deze feedback, denkt erover na en schrijft de code opnieuw. Ze deden dit tot wel drie keer.
De analogie: Het is als een leraar die een verslag nakijkt, fouten omcirkelt en de student vraagt het verslag te herschrijven.
Het resultaat: Deze "tweede kans" werkte wonderen. De veiligheid van de code sprong van ongeveer 71% veilig naar 79% veilig.
De adder onder het gras: De meeste verbetering vond plaats tijdens de eerste herschrijving. Bij de tweede en derde poging was de AI vooral bezig met het polijsten van kleine details. Het is alsoken het direct repareren van het slot op de voordeur, om vervolgens de volgende twee uur te besteden aan het zoeken naar een stofje op de deurklink.

3. De "Taal"-moeilijkheidsgraad

Niet alle programmeertalen zijn even moeilijk voor de AI om veilig te beheren.

De Makkelijke Modus: Python was het veiligst. Het is alsof je de AI vraagt een boomhut te bouwen; de AI kent de standaardregels goed.
De Moeilijke Modus: C en C# waren het gevaarlijkst. Deze talen zijn als het bouwen van een kerncentrale; één klein foutje in de bedrading veroorzaakt een meltdown. De AI had hier de meeste moeite mee.
Het Middenveld: Talen zoals Java, JavaScript en C++ vielen daar ergens tussenin.

4. De "Verraderlijke Bugs" versus de "Obvious Bugs"

De onderzoekers keken naar wat voor soort fouten de AI maakte.

De Makkelijke Fixes: De AI was eigenlijk best goed in het vermijden van "getextureerde" fouten, zoals het hardcoderen van een wachtwoord in de tekst of het openlaten van een achterdeur voor hackers om commando's te injecteren. Het is alsof de AI weet: "Oh, ik moet het wachtwoord niet op een plakbriefje schrijven."
De Moeilijke Fixes: De AI had de meeste moeite met cryptografie (versleuteling) en configuratiefouten. Dit zijn als het proberen te bakken van een taart met een specifieke, complexe chemische reactie. Als de temperatuur één graad afwijkt, gaat het mis. De AI zat vaak naast met de wiskunde of de instellingen.

5. Het "Regressie"-risico

Een interessant bevinding was dat de AI soms, wanneer het probeerde een fout te herstellen, per ongeluk iets anders kapot maakte dat wel gewoon werkte.

De analogie: Stel je voor dat je een lekkende kraan repareert. Je draait de klep aan, maar daardoor breek je per ongeluk de leiding erachter.
De bevinding: De AI deed dit af en toe, maar niet vaak genoeg om de voordelen teniet te doen. De "Netto Winst" (reparaties minus nieuwe fouten) was nog steeds positief.

De Kern van het Verhaal

Het artikel concludeert dat hoewel AI steeds beter wordt in het schrijven van code, het bij de eerste poging nog steeds veel beveiligingsfouten maakt. Echter, als je het de kans geeft om zijn eigen werk te beoordelen en één of twee keer te herstellen, krijg je aanzienlijk veiligere code.

Hun advies: Verwacht geen perfectie bij de eerste poging. Bouw in plaats daarvan een systeem waarbij de AI de code schrijft, een "beveiligingsrapportcijfer" krijgt en de belangrijkste problemen direct oplost. Dit één of twee keer doen vangt bijna alle voordelen op; het tien keer doen is slechts tijdverspilling.

Technische Samenvatting: Veilige Codegeneratie op Schaal met Reflexion

Probleemstelling
Hoewel Large Language Models (LLM's) breed worden toegepast voor het opstellen en refactoren van code, blijft de veiligheid van gegenereerde code een kritiek punt van zorg. Eerder onderzoek heeft vastgesteld dat LLM's vaak code produceren die functioneel correct is, maar onveilig, omdat ze kwetsbaarheden uit hun trainingsdata overnemen. Bestaande security-benchmarks vertonen beperkingen, waaronder een smalle taaldekking, afhankelijkheid van kleinschalige datasets en "cue contamination" (aanwijzingsbesmetting), waarbij prompts of identifiers onbedoeld informatie over kwetsbaarheden lekken, wat de onveiligheidsstatistieken kunstmatig verhoogt. Bovendien vertrouwen de meeste evaluaties op single-turn (zero-shot) prompting, waardoor het ongewijst blijft of iteratieve reflectie- en revisiestrategieën de veiligheidsresultaten effectief kunnen verbeteren. Er is een gebrek aan grootschalige, systematische evaluaties die gebruikmaken van hoogwaardige, validiteitsversterkte benchmarks om de effectiviteit van iteratieve zelfcorrectie bij veilige codegeneratie te meten.

Methodologie
De auteurs hebben een grootschalige evaluatie uitgevoerd met behulp van de Instruct Prime benchmark, een gecorrigeerde versie van CyberSecEval die compliance-vereiste prompts verwijdert en cue contamination vermindert. De studie bestond uit de volgende componenten:

Modellen: Vijf instructie-afgestemde code-LLM's werden geëvalueerd: Qwen2.5-Coder-32B, Codestral-22B, CodeLlama-34B, DeepSeek-Coder-33B en OpenCoder-8B.
Prompting Strategieën:
- Zero-Shot Baseline ( $t_0$ ): Modellen genereerden code op basis van enkel de taakbeschrijving zonder beveiligingsrichtlijnen.
- Reflexion Prompting ( $t_1, t_2, t_3$ ): Een iteratieve loop van drie rondes waarbij het model zijn vorige code ontvangt, samen met de resultaten van een statische security-analyse en specifieke hints over de gemarkeerde Common Weakness Enumeration (CWE) categorieën. Het model krijgt de instructie de code te reviseren om kwetsbaarheden te verwijderen terwijl de functionaliteit behouden blijft.
Security Assessment: De Insecure Code Detector (ICD), een statische, op CWE gebaseerde regelset, werd gebruikt om alle gegenereerde codesnippets te scannen.
Metrieken: De studie introduceerde drie metrieken om iteratieve prestaties te evalueren:
- Repair (Herstel): Het percentage eerder onveilige samples dat in de volgende ronde veilig werd.
- Regression (Regressie): Het percentage eerder veilige samples dat in de volgende ronde onveilig werd.
- NetGain (Nettowinst): Het verschil tussen de Repair- en Regression-percentages.
Post-Processing: Om een eerlijke evaluatie te garanderen, werd de output gefilterd om alleen "Complete Code" te bevatten. Niet-code of gemengde outputs werden als onveilig gemarkeerd om te voorkomen dat modellen de security-checks omzeilen door tekst in plaats van code te genereren.

Belangrijkste Bijdragen

Grootschalige Evaluatie: De studie biedt een uitgebreide beoordeling van veilige codegeneratie over vijf modellen, acht programmeertalen en 50 CWE-categorieën met behulp van de gevalideerde Instruct Prime benchmark.
Iteratieve Reflexion Analyse: Het is de eerste systematische evaluatie van zelfreflectie voor veilige codegeneratie op schaal, waarbij wordt getest of modellen de veiligheid iteratief kunnen verbeteren via drie rondes van revisie.
Uitgebreide Metrieken: Het artikel gaat verder dan eenvoudige nauwkeurigheid door Repair, Regression en NetGain metrieken te rapporteren, wat een genuanceerd beeld geeft van hoe iteratieve strategieën de veiligheid verbeteren zonder nieuwe kwetsbaarheden te introduceren.
Replicatiepakket: Een volledig replicatiepakket inclusief prompts, generatielogs en scoring-artefacten is beschikbaar gesteld om auditing en hergebruik mogelijk te maken.

Resultaten

Baseline Onveiligheid: Bij de zero-shot baseline ( $t_0$ $t_{0}$ ) is onveiligheid wijdverspreid, waarbij ongeveer 25–33% van de gegenereerde programma's onveilig is.
- Taalvariantie: Python leverde de hoogste veiligheidspercentages op (78–88%), terwijl C en C# de laagste lieten zien (55–67%).
- CWE Variantie: Getypeerde kwetsbaarheden zoals XSS (CWE-79), code-injectie (CWE-94) en hard-coded geheimen (CWE-798) werden betrouwbaar afgehandeld (85–90% veilige rates). Daarentegen waren zwakke cryptografie (CWE-338) en configuratie-afhankelijke bugs het moeilijkst te vermijden, waarbij de veilige rates daalden naar 10–35% voor specifieke categorieën.
Impact van Reflexion: Het toepassen van de reflexion-strategie verbeterde de gemiddelde veilige generatie-nauwkeurigheid van 70,74% bij $t_0$ naar 79,43% bij $t_3$ .
- Verminderde Meeropbrengst: De grootste winsten vonden plaats in de eerste ronde ( $t_1$ , +6,00 procentpunt). Opmerkelijke verbeteringen in latere rondes ( $t_2, t_3$ ) waren kleiner (+1,66 en +1,03 pp, respectievelijk).
- Modelprestaties: QwenCoder en Codestral vertoonden de meest significante verbeteringen (ongeveer +11 procentpunt). OpenCoder liet meer bescheiden winsten zien.
- Regressies: Hoewel reparaties veel voorkomend waren, introduceerden latere rondes incidenteel regressies (1–2%), waarbij veilige code werd gereviseerd tot onveilige code.
Optimale Strategie: De gegevens suggereren dat één tot twee rondes van reflexion de meerderheid van de veiligheidsvoordelen opleveren, waarbij extra iteraties leiden tot verminderde meeropbrengst.

Betekenis en Claims
Het artikel claimt dat onveiligheid een wijdverspreid probleem blijft in door LLM's gegenereerde code, waarbij ongeveer een kwart tot een derde van de initiële outputs kwetsbaarheden bevat. De studie demonstreert dat reflexion prompting een effectief, training-vrij mechanisme is om dit onveiligheidspercentage aanzienlijk te verlagen. De auteurs benadrukken echter dat reflexion het risico niet volledig elimineert; het corrigeert primair de meest directe en overduidelijke fouten in de eerste iteratie.

De auteurs concluderen dat hoewel iteratieve reflectie de veiligheid verbetert, de voordelen onderhevig zijn aan verminderde meeropbrengst en het risico op regressie. Ze stellen een praktische beleidsregel voor: draai standaard één ronde van reflexion, ga alleen door voor gevallen die nog steeds onveilig zijn, en stop zodra de NetGain weinig verbetering laat zien of wanneer de regressies het niveau van de reparaties naderen. De studie benadrukt dat hoewel LLM's verbeteren, specifieke kwetsbaarheidsfamilies (cryptografische zwakheden, data-authenticiteit) en lagere talen (C, C#) aanzienlijke uitdagingen blijven die verdere investeringen in veilige defaults en hoogwaardige trainingsdata vereisen.