💻 computer science

Does Fixing Break Security? An Empirical Study of Security Degradation in Iterative LLM-Driven Infrastructure-as-Code Repair

Deze empirische studie analyseert 5.968 iteratieve door LLM gestuurde Infrastructure-as-Code reparatiescenario's om te onthullen dat hoewel beveiligingsregressies voorkomen in tot 13,8% van de gevallen onder standaarddetectie, een conservatievevere strengere modus-analyse een verdedigbare degradatiegraad van 3,3% laat zien, die primair wordt gedreven door herstructurering van resources en wordt getemperd door reparaties te stoppen na de derde iteratie.

Oorspronkelijke auteurs: Benjamin Agyekum, Fabio Santos

Gepubliceerd 2026-08-14

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Benjamin Agyekum, Fabio 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 gigantisch, ingewikkeld kasteel bouwt van digitale blokken. Dit is niet zomaar een kasteel; dit is de infrastructuur die het internet, je favoriete apps en clouddiensten aanstuurt. In de wereld van software engineering wordt dit Infrastructure-as-Code (IaC) genoemd. In plaats van op knopjes te klikken in een menu, schrijven engineers tekstbestanden (code) die de computer precies vertellen hoe ze deze digitale kastelen moeten bouwen. Onlangs zijn we begonnen met het gebruik van super-slimme AI-assistenten, bekend als Large Language Models (LLM's), om deze code voor ons te schrijven. Het is alsof je een robotarchitect inhuurt die in seconden blauwdrukken kan ontwerpen.

Maar hier zit de adder onder het gras: robots maken fouten. Soms hebben de blauwdrukken die ze tekenen beveiligingslekken—zoals een openstaande voordeur of het vergeten vergrendelen van de schatkist. Om dit op te lossen, gebruiken we een "feedbackloop". We draaien een beveiligingsscanner (een digitale inspecteur) die het werk van de robot controleert, de fouten aanwijst en het slechte nieuws terugstuurt naar de robot. De robot probeert vervolgens de code te repareren en stuurt deze terug voor een volgende controle. Deze cyclus herhaalt zich, in de hoop dat het kasteel bij elke ronde veiliger wordt. De grote vraag is: breekt het oplossen van het ene probleem per ongeluk iets anders dat al veilig was? Het is als het repareren van een gat in een boot, waarbij je per ongeluk een gat in de romp slaat terwijl je bezig bent. Dit artikel duikt diep in dat exacte scenario om te zien of onze AI-helpers de boel echt veiliger maken of alleen maar een puinhoop maken.

Het Dilemma van de Robotarchitect: Wanneer Fixes de Fixes Breken

In dit onderzoek besloten onderzoekers Benjamin Agyekum en Fabio Santos detective te spelen met een enorme dataset van deze AI-reparatiepogingen. Ze bekeken bijna 6.000 verschillende scenario's waarin een AI probeerde cloud-infrastructuurcode te bouwen of te repareren. Ze volgden wat er gebeurde over 5 rondes van reparaties, waarbij ze 30 specifieke beveiligingscontroles bijhielden (zoals "Is de data versleuteld?" of "Is de toegang afgeschermd?").

Hun belangrijkste ontdekking is een beetje een verrassing: Ja, dingen repareren kan de beveiliging breken, maar het is niet zo eng als het op het eerste gezicht lijkt.

Toen ze naar de ruwe cijfers keken met een "standaard" manier van tellen, ontdekten ze dat de AI in 13,8% van de gevallen een beveiligingsregel die eerder wel werkte, wist te breken terwijl hij iets anders probeerde te repareren. Dat klinkt als veel, toch? Maar de onderzoekers realiseerden zich dat de manier waarop ze telden een beetje lastig was. Omdat de code vaak uit veel verschillende onderdelen bestaat (zoals meerdere digitale sloten op een gebouw), kan de AI één slot repareren maar per ongeluk de status van een ander onderdeel veranderen, zelfs als de eigenlijke beveiliging niet echt in gevaar is gekomen.

Toen ze overschakelden naar een "strikte" manier van tellen—waarbij ze alleen keken naar duidelijke, onmiskenbare gevallen waarin de beveiliging daadwerkelijk verslechterde—daalde het aantal spectaculair naar slechts 3,3% van de scenario's. Dit suggereert dat de meeste van de "breuken" slechts verwarrende meetfoutjes waren veroorzaakt door de complexiteit van de code, en geen echte beveiligingscatastrofes.

Het "Waarom" en "Hoe" van de Breuk

Dus, wanneer de AI wél de mist in gaat, wat is er dan aan de hand? De onderzoekers ontdekten dat de schuldige bijna altijd resource restructuring (het herstructureren van bronnen) is. Stel je voor dat de robotarchitect besluit om een hele muur te herbouwen in plaats van alleen een barst te repareren. In dat proces kan hij vergeten de beveiligingscamera weer op de nieuwe muur te plaatsen. Dit gebeurde in 79% van de gevallen waarin de beveiliging daadwerkelijk achteruitging.

Ze merkten ook iets interessants op over de "persoonlijkheid" van de AI-modellen. Eén model (Mistral) leek volgens de standaard telmethode 17 keer vaker dingen te breken dan een ander model (Gemini). Echter, toen ze de strikte methode gebruikten, brak geen van beide modellen exclusief iets. Dit betekent dat het "slechte" model niet daadwerkelijk meer gevaarlijke gaten creëerde; het creëerde simpelweg complexere codestructuren die de telmethode in verwarring brachten.

Het Zoete Punt: Wanneer te Stoppen

Een van de meest praktische bevindingen gaat over wanneer te stoppen. De AI blijft de code verbeteren, maar stopt de AI ooit? De studie suggereert dat de 3e iteratie (de derde keer dat de AI de code probeert te repareren) het ideale punt is.

Tegen de 3e poging is de code ongeveer 83,1% veilig.
Als je doorgaat naar de 4e of 5e poging, win je nauwelijks extra beveiliging (misschien 0,3% meer), maar je vergroot het risico dat je weer dingen breekt.

Het is als het afstemmen van een radio: na een bepaald punt zorgt het draaien aan de knop alleen maar voor meer ruis zonder een duidelijker station te vinden.

De Zilveren Rand: Zelfcorrectie

Hier is het meest hoopvolle deel van het verhaal. De onderzoekers ontdekten dat wanneer de AI per ongeluk een beveiligingsregel breekt, hij dit vaak zelf weer herstelt! In ongeveer 36,6% van de gevallen corrigeert de volgende ronde van reparaties de fout die de AI zojuist heeft gemaakt. Het is alsof de robotarchitect beseft: "Oeps, ik heb de verkeerde deur eraf gehaald," en hem in de volgende stap weer terugplaatst.

Ze vonden echter ook een "touwtrekwedstrijd"-effect. In ongeveer 28,5% van de gevallen zouden de beveiligingscontroles heen en weer springen—geslaagd, gefaald, geslaagd, gefaald—als een pendule die niet kan beslissen waar hij moet stoppen. Dit gebeurt meestal bij complexe toegangscontroles, wat suggereert dat de AI nog steeds aan het uitzoeken is wat de beste manier is om die specifieke onderdelen te bouwen.

De Conclusie

Dit artikel vertelt ons dat hoewel iteratieve AI-reparatie een krachtig hulpmiddel is, we voorzichtig moeten zijn met hoe we het succes ervan meten.

Raak niet in paniek over elke glitch: De meeste schijnbare beveiligingsbreuken zijn slechts verwarrende meetartefacten, geen echte gevaren.
Pas op voor grote verbouwingen: Als de AI hele secties van de code begint af te breken om een kleine bug te repareren, is dat het moment waarop de beveiliging het meest waarschijnlijk glipt.
Stop bij drie: Laat de AI drie keer proberen de code te repareren, en stop dan. Verder gaan brengt meestal meer risico dan rendement.
Gebruik de juiste tools: Als je superveilig wilt zijn, gebruik dan een "strikte" manier van controleren die verwarrende meervoudige fouten negeert, maar houd wel de "standaard" meldingen in de gaten voor het geval dat.

Kortom, de AI is een behulpzame leerling, maar hij heeft een menselijke supervisor nodig om te weten wanneer hij de moersleutel moet laten rusten, anders draait hij de bout misschien zo strak aan dat de hele machine knapt.

Technisch overzicht: Veroorzaakt reparatie verslechtering van de beveiliging? Een empirische studie naar beveiligingsdegradatie in iteratieve door LLM gestuurde Infrastructure-as-Code reparatie

Probleemstelling

Hoewel iteratieve feedbackloops—waarbij validators zoals Checkov en terraform validate foutsignalen terugkoppelen naar Large Language Models (LLM's) voor opeenvolgende reparatiepogingen—de dominante paradigma zijn geworden voor het verbeteren van door LLM gegenereerde Infrastructure-as-Code (IaC), heeft eerder onderzoek grotendeels vertrouwd op cumulatief-beste metrieken. Deze metrieken rapporteren de hoogste behaalde compliance over alle iteraties heen, die constructief monotoon niet-dalend zijn. Bijgevolg is het ruwe per-iteratie beveiligingstraject in het IaC-domein nooit onderzocht.

Deze studie onderzoekt het fenomeen van beveiligingsregressie: gevallen waarin een voorheen geslaagde beveiligingscontrole (specifiek CIS Benchmark-controles) faalt na een reparatie-iteratie die bedoeld was om andere problemen op te lossen. In tegenstelling tot algemene studies naar code-reparatie (bijv. Shukla et al. [25], Chen et al. [7]), die zich richten op imperatieve talen en kwetsbaarheidsaantallen, onderzoekt dit onderzoek de unieke uitdagingen van IaC. IaC is declaratief, en beveiligingscontroles mappen naar specifieke configuratie-eigenschappen op het niveau van de resource. Een cruciaal onderscheid is dat één enkele Checkov check ID kan gelden voor meerdere resources binnen een enkele configuratie, wat een klasse van multi-resource ambiguïteit creëert waarbij een controle voor sommige resources slaagt en voor andere tegelijkertijd faalt. Deze ambiguïteit compliceert de definitie van een "regressie" in IaC vergeleken met algemene code.

Methodologie

De auteurs voerden een grootschalige empirische studie uit door 5.968 scenario-tijdlijnen uit de IaC-Eval benchmark te analyseren. Het studieontwerp bestond uit:

Configuraties: 15 verschillende experimentele configuraties bestaande uit twee model-specifieke Retrieval-Augmented Generation (RAG) opstellingen (Gemini en Mistral) en negen model-geaggregeerde non-RAG opstellingen (Zero-Shot, Few-Shot, Chain-of-Thought), elk uitgevoerd bij drie temperaturen (0.1, 0.4, 0.7).
Proces: Elk scenario werd door maximaal 5 reparatie-iteraties geleid. De pipeline genereerde Terraform-code, valideerde deze en voedde fouten terug aan de LLM.
Datavolume: De analyse besloeg 4.440 iteratie-transities waar Checkov-data beschikbaar was voor zowel de pre- als de post-reparatie staat.
Tracking: De studie volgde 30 individuele Checkov check ID's die in kaart zijn gebracht naar CIS AWS Foundations Benchmark-controles over zes beveiligingscategorieën (encryptie, toegangscontrole, logging, netwerken, dataprotectie en overig).
Detectiemodi: Om multi-resource ambiguïteit aan te pakken, werden twee detectiemodi geformaliseerd:
- Standaard (Inclusief): Telt een regressie als een check ID voorkomt in de geslaagde set bij iteratie $i$ en in de gefaalde set bij iteratie $i+1$ , ongeacht of het ook voor andere resources slaagde.
- Strikt (Exclusief): Telt een regressie alleen als een check ID exclusief geslaagd was (geen fouten) bij iteratie $i$ en exclusief gefaald was (geen successen) bij iteratie $i+1$ .
Oorzaakanalyse: Code-diffs werden geclassificeerd in vier onderling uitsluitende categorieën: Resource Restructuring, Configuration Drift, Argument Removal en Unclassified.
Statistische Analyse: De studie maakte gebruik van Chi-kwadraat toetsen, Mann-Whitney U-testen, Fisher's exact test en effectgrootte-maten (Cramér's V, Cohen's d) met Bonferroni-correctie voor meervoudige vergelijkingen.

Belangrijkste Bijdragen

Eerste Grootschalige Empirische Studie: Dit is de eerste studie die het per-iteratie beveiligingstraject van iteratieve door LLM gestuurde IaC-reparatie analyseert, waarbij verder wordt gekeken dan cumulatief-beste metrieken om beveiligingsregressies te detecteren.
Regressie Taxonomie: De auteurs leiden een taxonomie van regressie-oorzaken af, waarbij zij Resource Restructuring identificeren als de dominante oorzaak (79.0% in standaardmodus).
Onderscheid in Detectiemodus: Het artikel formaliseert het onderscheid tussen Standaard vs. Strikt detectie, en toont aan dat de keuze van de detectiemodus de conclusies over modelprestaties en risicoverdeling kwalitatief verandert.
Kwantificering van de Beveiliging-Correctheid Trade-off: De studie kwantificeert de relatie tussen code-wijzigingen en beveiligingsdegradatie, waarbij wordt aangetoond dat regressie-transities aanzienlijk hogere code-churn en check-volatiliteit met zich meebrengen.
Actiegerichte Richtlijnen: De studie biedt specifieke richtlijnen voor iteratie-budgetten en configuratiekeuzes, waarbij iteratie 3 wordt geïdentificeerd als het optimale stopmoment en de zelfcorrigerende capaciteiten van de feedbackloop worden benadrukt.

Belangrijkste Resultaten

RQ1: Frequentie van Regressies

Standaard Modus: 13.8% van de scenario's (24.8% van de transities) vertoonde ten minste één beveiligingsregressie.
Strikte Modus: Wanneer gefilterd wordt op unambiguous, exclusieve fouten, daalt het percentage naar 3.3% van de scenario's (5.2% van de transities).
Interpretatie: Het gat tussen de standaard en strikte modus geeft aan dat ongeveer 76% van de schijnbaar geregistreerde regressies multi-resource artefacten zijn in plaats van echte exclusieve fouten.

RQ2: Kwetsbare Beveiligingscontroles

Standaard Modus: Toegangscontrole domineert (38.5%), gedreven door IAM-gerelateerde controles (bijv. CKV_AWS_356, CKV_AWS_111).
Strikte Modus: De rangorde keert om. Netwerken (42.6%) en Encryptie (21.6%) worden de dominante risico's, terwijl Toegangscontrole daalt naar 9.2%.
Implicatie: Regressies in toegangscontrole zijn grotendeels artefacten van multi-resource ambiguïteit (bijv. één IAM-rol slaagt terwijl een andere faalt), terwijl netwerk- en encryptie-regressies echte exclusieve fouten vertegenwoordigen.

RQ3: Configuratiefactoren

Model Gap (RAG-configuraties): In de standaardmodus vertoonde Mistral een 17× hogere regressieratio dan Gemini. Echter, dit gat verdwijnt volledig in de strikte modus voor RAG-configuraties, waar noch RAG+Gemini, noch RAG+Mistral een enkele strikte-modus scenario-regressie produceerde (0 van de 1.297 en 0 van de 929 respectievelijk). Dit bevestigt dat het gat te wijten was aan multi-resource ambiguïteit in plaats van exclusieve check-fouten.
RAG-effect: RAG lijkt een hogere regressieratio te hebben in de standaardmodus, maar een lagere (nul) ratio in de strikte modus vergeleken met non-RAG strategieën. Dit suggereert dat RAG meer uitgebreide multi-resource structuren genereert (wat de standaard-tellingen verhoogt), maar betere gronding biedt voor individuele beveiligingseigenschappen (wat exclusieve fouten vermindert).
Temperatuur: Temperatuur had een statistisch significant maar praktisch verwaarloosbaar effect (Cramér's V = 0.049).

RQ4: Beveiliging-Correctheid Trade-off

Code Churn: Regressie-transities bevatten 2.6× meer code-churn (gewijzigde regels) en een lagere tekstuele gelijkenis vergeleken met non-regressie transities.
Check Volatiliteit: Dit is de sterkste voorspeller van regressie. Regressie-transities vertonen 4.9× hogere strict-mode check volatiliteit (Cohen's d = 1.49).
Syntax Fixes: Transities die direct volgen op een syntax-fix dragen een 21% hoger regressierisico met zich mee in de standaardmodus.
Clean Timelines: Tegenintuïtief genoeg hadden scenario's die gedurende de hele tijd geldige syntax behielden ("clean" timelines) een hogere regressieratio (20.8%) dan scenario's die worstelden met syntaxfouten (12.1%).

Aanvullende Bevindingen

Zelfcorrectie: 36.6% van de standaard-modus regressies corrigeerde zichzelf binnen gemiddeld 1.2 iteraties, wat suggereert dat de feedbackloop vaak zijn eigen fouten oppikt.
Oscillatie: 28.5% van de scenario's vertoonde oscillerende controles (slagen, falen, en dan weer slagen), met name in IAM-configuraties.
Optimaal Stoppen: Iteratie 3 wordt geïdentificeerd als het optimale stopmoment, waarbij 83.1% van de pass-rate wordt gevangen (binnen 0.3 procentpunt van de piek) terwijl het regressierisico beheersbaar blijft.

Betekenis en Claims

Het artikel claimt het eerste empirische bewijs te leveren dat iteratieve IaC-reparatie beveiligingsregressies introduceert, hoewel de ernst afhangt van de detectiemethodologie. De auteurs stellen dat hoewel de "conservatieve, verdedigbare rate" van echte exclusieve regressies ongeveer 3.3% is, het fenomeen niet te negeren is en volledig wordt gemaskeerd door de cumulatief-beste metrieken die in eerder werk werden gebruikt.

De studie benadrukt dat resource restructuring de primaire drijfveer van degradatie is, en niet enkel de prompting-strategie of temperatuur. De bevindingen motiveren het ontwerp van beveiligingsbewuste feedbackloops die:

Onderscheid maken tussen multi-resource artefacten en exclusieve fouten.
"Beveiligingsankering" implementeren om te voorkomen dat het model volledige resource-blokken regenereert wanneer slechts kleine aanpassingen nodig zijn.
Een iteratie-budget van ongeveer 3 iteraties hanteren om de compliance-winsten af te wegen tegen de risico's op regressie.
Check-volatiliteit gebruiken als een real-time signaal om reparatielussen te stoppen of te markeren.

De auteurs concluderen dat hoewel iteratieve reparatie de algehele compliance verbetert, het een specifieke klasse van beveiligingsdegradatie introduceert die nieuwe detectiemethodologieën en operationele waarborgen vereist, vooral gezien de declaratieve en multi-resource aard van IaC.