💻 computer science

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

Questo studio empirico analizza 5.968 scenari iterativi di riparazione di Infrastructure-as-Code guidati da LLM per rivelare che, mentre le regressioni di sicurezza si verificano in circa il 13,8% dei casi sotto una rilevazione standard, un'analisi in modalità rigorosa più conservativa mostra un tasso di degradazione difendibile del 3,3%, principalmente causato dalla ristrutturazione delle risorse e mitigato dall'interruzione delle riparazioni dopo la terza iterazione.

Autori originali: Benjamin Agyekum, Fabio Santos

Pubblicato 2026-08-14

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Benjamin Agyekum, Fabio Santos

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di stare costruendo un castello massiccio e intricato fatto di blocchi digitali. Non è un castello qualsiasi; è l'infrastruttura che fa funzionare internet, le tue app preferite e i servizi cloud. Nel mondo dell'ingegneria del software, questo si chiama Infrastructure-as-Code (IaC). Invece di cliccare pulsanti in un menu, gli ingegneri scrivono file di testo (codice) che dicono al computer esattamente come costruire questi castelli digitali. Recentemente, abbiamo iniziato a usare assistenti IA super intelligenti, noti come Large Language Models (LLM), per scrivere questo codice per noi. È come assumere un architetto robotico capace di tracciare progetti in pochi secondi.

Ma ecco il problema: i robot commettono errori. A volte, i progetti che disegnano hanno falle di sicurezza — come lasciare la porta d'ingresso spalancata o dimenticare di chiudere il forziere del tesoro. Per risolvere questo, usiamo un "ciclo di feedback". Eseguiamo uno scanner di sicurezza (un ispettore digitale) che controlla il lavoro del robot, segnala gli errori e rimanda le cattive notizie al robot. Il robot poi prova a correggere il codice e lo rimanda per un altro controllo. Questo ciclo si ripete, sperando che il castello diventi più sicuro a ogni round. La grande domanda è: correggere un problema rompe accidentalmente qualcosa che era già sicuro? È come cercare di tappare un buco in una barca, solo per finire accidentalmente per fare un buco nello scafo mentre ci si lavora. Questo articolo approfondisce proprio questo scenario per vedere se i nostri aiuti IA stiano effettivamente rendendo le cose più sicure o stiano solo creando un pasticcio.

Il dilemma dell'architetto robotico: quando le correzioni rompono le correzioni

In questo studio, i ricercatori Benjamin Agyekum e Fabio Santos hanno deciso di giocare a fare i detective con un enorme dataset di questi tentativi di riparazione dell'IA. Hanno esaminato quasi 6.000 scenari diversi in cui un'IA ha cercato di costruire o riparare codice di infrastruttura cloud. Hanno osservato cosa accadeva in 5 round di riparazioni, tracciando 30 controlli di sicurezza specifici (come "I dati sono criptati?" o "L'accesso è blindato?").

La loro scoperta principale è un po' un colpo di scena: Sì, correggere le cose può rompere la sicurezza, ma non è così spaventoso come sembra.

Quando hanno esaminato i numeri grezzi usando un modo "standard" di contare, hanno scoperto che nel 13,8% dei casi l'IA è riuscita a rompere una regola di sicurezza che precedentemente funzionava mentre cercava di riparare qualcos'altro. Sembra molto, vero? Ma i ricercatori si sono resi conto che il modo in cui stavano contando era un po' complicato. Poiché il codice spesso coinvolge molte parti diverse (come molte serrature digitali su un edificio), l'IA potrebbe riparare una serratura ma accidentalmente sballare lo stato di un'altra, anche se la sicurezza reale non è stata compromessa.

Quando sono passati a un modo di contare "rigoroso" — guardando solo i casi chiari e innegabili in cui la sicurezza è effettivamente peggiorata — il numero è sceso drasticamente solo al 3,3% degli scenari. Ciò suggerisce che la maggior parte dei "cedimenti" erano solo glitch di misurazione confusi causati dalla complessità del codice, non veri disastri di sicurezza.

Il "Perché" e il "Come" del cedimento

Quindi, quando l'IA sbaglia, cosa sta succedendo? I ricercatori hanno scoperto che il colpevole è quasi sempre la ristrutturazione delle risorse. Immaginate che l'architetto robot decidano di ricostruire completamente una parete invece di limitarsi a tappare una crepa. Facendo ciò, potrebbe dimenticarsi di rimettere la telecamera di sicurezza sulla nuova parete. Questo è accaduto nel 79% dei casi in cui la sicurezza è effettivamente regredita.

Hanno anche notato qualcosa di interessante sulla "personalità" dei modelli di IA. Un modello (Mistral) sembrava rompere le cose 17 volte più spesso di un altro (Gemini) usando il metodo di conteggio standard. Tuttavia, quando hanno usato il metodo rigoroso, nessuno dei due modelli ha rotto nulla esclusivamente. Questo significa che il modello "cattivo" non stava creando buchi più pericolosi; stava solo creando strutture di codice più complesse che confondevano il metodo di conteggio.

Il punto di equilibrio: quando smettere di riparare

Uno dei risultati più pratici riguarda il quando fermarsi. L'IA continua a cercare di migliorare il codice, ma si ferma mai? Lo studio suggerisce che la terza iterazione (la terza volta che l'IA prova a correggere il codice) è il punto di equilibrio.

Entro il 3° tentativo, il codice è sicuro circa all'83,1%.
Se si continua fino al 4° o 5° tentativo, si guadagna pochissimo in termini di sicurezza (forse solo lo 0,3%), ma si inizia ad aumentare di nuovo il rischio di rompere le cose.

È come sintonizzare una radio: dopo un certo punto, girare la manopola crea solo più interferenze senza trovare una stazione più chiara.

Il lato positivo: l'auto-correzione

Ecco la parte più speranzosa della storia. I ricercatori hanno scoperto che quando l'IA effettivamente rompe una regola di sicurezza, spesso si corregge da sola! Circa il 36,6% delle volte, il round di riparazione successivo corregge l'errore appena commesso dall'IA. È come se l'architetto robot si rendesse conto: "Ops, ho tolto la porta sbagliata", e la rimette al suo posto nel passaggio successivo.

Tuttavia, hanno anche trovato un effetto "tiro alla fune". Circa il 28,5% delle volte, i controlli di sicurezza oscillavano avanti e indietro — passa, fallisce, passa, fallisce — come un pendolo che non riesce a decidere dove fermarsi. Questo accade solitamente con i controlli di accesso complessi, suggerendo che l'IA stia ancora cercando il modo migliore per costruire quelle parti specifiche.

In sintesi

Questo articolo ci dice che, sebbene la riparazione iterativa tramite IA sia uno strumento potente, dobbiamo fare attenzione a come misuriamo il suo successo.

Non entrate in panico per ogni glitch: La maggior parte dei problemi di sicurezza apparenti sono solo artefatti di misurazione confusi, non pericoli reali.
Attenzione alle grandi ristrutturazioni: Se l'IA inizia a demolire intere sezioni di codice per correggere un piccolo bug, è allora che la sicurezza è più soggetta a scivolare.
Fermatevi al terzo: Lasciate che l'IA provi tre volte a correggere il codice, poi basta così. Andare oltre di solito aggiunge più rischi che benefici.
Usate gli strumenti giusti: Se volete essere super sicuri, usate un modo di controllare "rigoroso" che ignori gli errori confusi su parti multiple, ma tenete d'occhio gli avvisi "standard" per sicurezza.

In breve, l'IA è un apprendista utile, ma ha bisogno di un supervisore umano che sappia quando smettere di girare la chiave inglese, altrimenti potrebbe finire per stringere il bullone così forte da spezzare l'intera macchina.

Sintesi Tecnica: La riparazione compromette la sicurezza? Uno studio empirico sulla degradazione della sicurezza nella riparazione iterativa di Infrastructure-as-Code guidata da LLM

Definizione del Problema

Sebbene i cicli di feedback iterativi — in cui i validatori come Checkov e terraform validate forniscono segnali di errore agli Large Language Models (LLM) per successivi tentativi di riparazione — siano diventati il paradigma dominante per migliorare l'Infrastructure-as-Code (IaC) generata da LLM, la ricerca precedente si è ampiamente basata su metriche cumulative-best. Queste metriche riportano la massima conformità raggiunta attraverso tutte le iterazioni, che sono monotonicamente non decrescenti per costruzione. Di conseguenza, la traiettoria di sicurezza per singola iterazione non è mai stata esaminata nel dominio dell'IaC.

Questo studio affronta il fenomeno della regressione della sicurezza: casi in cui un controllo di sicurezza precedentemente superato (specificamente i controlli dei benchmark CIS) fallisce dopo un'iterazione di riparazione intesa a risolvere altri problemi. A differenza degli studi sulla riparazione di codice generico (ad es. Shukla et al. [25], Chen et al. [7]) che si concentrano su linguaggi imperativi e conteggi di vulnerabilità, questa ricerca investiga le sfide uniche dell'IaC. L'IaC è dichiarativa e i controlli di sicurezza mappano proprietà di configurazione specifiche a livello di risorsa. Una distinzione critica è che un singolo ID di controllo Checkov può applicarsi a più risorse all'interno di una singola configurazione, creando una classe di ambiguità multi-risorsa in cui un controllo può risultare superato per alcune risorse e fallito per altre simultaneamente. Questa ambiguità complica la definizione di una "regressione" nell'IaC rispetto al codice generale.

Metodologia

Gli autori hanno condotto uno studio empirico su larga scala analizzando 5.968 timeline di scenari dal benchmark IaC-Eval. Il design dello studio ha previsto:

Configurazioni: 15 configurazioni sperimentali distinte comprendenti due setup di Generazione Aumentata da Recupero (RAG) specifici per modello (Gemini e Mistral) e nove setup non-RAG aggregati per modello (Zero-Shot, Few-Shot, Chain-of-Thought), ciascuno eseguito a tre temperature (0.1, 0.4, 0.7).
Processo: Ogni scenario è stato sottoposto a fino a 5 iterazioni di riparazione. La pipeline ha generato codice Terraform, lo ha validato e ha fornito gli errori all'LLM.
Volume di Dati: L'analisi ha coperto 4.440 transizioni di iterazione in cui i dati di Checkov erano disponibili sia per lo stato pre-riparazione che per quello post-riparazione.
Tracciamento: Lo studio ha tracciato 30 singoli ID di controllo Checkov mappati ai controlli CIS AWS Foundations Benchmark in sei categorie di sicurezza (crittografia, controllo degli accessi, logging, networking, protezione dei dati e altro).
Modalità di Rilevamento: Per affrontare l'ambiguità multi-risorsa, sono state formalizzate due modalità di rilevamento:
- Standard (Inclusiva): Conta una regressione se un ID di controllo appare nell'insieme dei superati all'iterazione $i$ e nell'insieme dei falliti all'iterazione $i+1$ , indipendentemente dal fatto che sia passato anche per altre risorse.
- Strict (Esclusiva): Conta una regressione solo se un ID di controllo era esclusivamente superato (nessun fallimento) all'iterazione $i$ ed esclusivamente fallito (nessun superamento) all'iterazione $i+1$ .
Analisi delle Cause Radice: I diff del codice sono stati classificati in quattro categorie mutuamente esclusive: Ristrutturazione delle Risorse, Drift della Configurazione, Rimozione di Argomenti e Non Classificato.
Analisi Statistica: Lo studio ha utilizzato test Chi-quadrato, test Mann-Whitney U, test esatto di Fisher e misure di dimensione dell'effetto (Cramér's V, Cohen's d) con correzione di Bonferroni per confronti multipli.

Contributi Chiave

Primo Studio Empirico su Larga Scala: Questo è il primo studio ad analizzare la traiettoria di sicurezza per iterazione della riparazione IaC iterativa guidata da LLM, andando oltre le metriche cumulative-best per rilevare le regressioni di sicurezza.
Tassonomia delle Regressioni: Gli autori derivano una tassonomia delle cause radice delle regressioni, identificando la Ristrutturazione delle Risorse come la causa dominante (79.0% in modalità standard).
Distinzione delle Modalità di Rilevamento: Il documento formalizza la distinzione tra Standard e Strict, dimostrando che la scelta della modalità di rilevamento cambia qualitativamente le conclusioni sulle prestazioni del modello e sulla distribuzione del rischio.
Quantificazione del Trade-off Sicurezza-Correttezza: Lo studio quantifica la relazione tra modifiche al codice e degradazione della sicurezza, mostrando che le transizioni di regressione comportano un churn del codice e una volatilità dei controlli significativamente più elevati.
Guida Azionabile: Lo studio fornisce indicazioni specifiche sui budget di iterazione e sulle scelte di configurazione, identificando l'iterazione 3 come il punto di arresto ottimale e sottolineando le capacità di auto-correzione del ciclo di feedback.

Risultati Chiave

RQ1: Frequenza delle Regressioni

Modalità Standard: Il 13.8% degli scenari (24.8% delle transizioni) ha presentato almeno una regressione di sicurezza.
Modalità Strict: Filtrando per fallimenti esclusivi e univoci, il tasso scende al 3.3% degli scenari (5.2% delle transizioni).
Interpretazione: Il divario tra le modalità standard e strict indica che circa il 76% delle apparenti regressioni sono artefatti di misurazione multi-risorsa piuttosto che veri fallimenti esclusivi.

RQ2: Controlli di Sicurezza Vulnerabili

Modalità Standard: Il Controllo degli Accessi domina (38.5%), guidato da controlli relativi a IAM (ad es. CKV_AWS_356, CKV_AWS_111).
Modalità Strict: La classifica si inverte. Networking (42.6%) e Crittografia (21.6%) diventano i rischi dominanti, mentre il Controllo degli Accessi scende al 9.2%.
Implicazione: Le regressioni del controllo degli accessi sono in gran parte artefatti dell'ambiguità multi-risorsa (ad es. un ruolo IAM passa mentre un altro fallisce), mentre le regressioni di networking e crittografia rappresentano veri fallimenti esclusivi.

RQ3: Fattori di Configurazione

Gap del Modello (Configurazioni RAG): In modalità standard, Mistral ha mostrato un tasso di regressione 17 volte superiore rispetto a Gemini. Tuttavia, questo divario svanisce completamente in modalità strict per le configurazioni RAG, dove né RAG+Gemini né RAG+Mistral hanno prodotto una singola regressione di scenario in modalità strict (0 di 1.297 e 0 di 929 rispettivamente). Ciò conferma che il divario era dovuto all'ambiguità multi-risorsa piuttosto che a fallimenti esclusivi dei controlli.
Effetto RAG: Il RAG sembra avere un tasso di regressione più elevato in modalità standard, ma un tasso inferiore (zero) in modalità strict rispetto alle strategie non-RAG. Ciò suggerisce che il RAG genera strutture multi-risorsa più complete (aumentando i conteggi standard) ma fornisce un migliore radicamento per le singole proprietà di sicurezza (riducendo i fallimenti esclusivi).
Temperatura: La temperatura ha avuto un effetto statisticamente significativo ma praticamente trascurabile (Cramér's V = 0.049).

RQ4: Trade-off Sicurezza-Correttezza

Code Churn: Le transizioni di regressione comportano 2.6× più code churn (righe cambiate) e una minore similarità testuale rispetto alle transizioni senza regressione.
Volatilità dei Controlli: Questo è il predittore più forte di regressione. Le transizioni di regressione mostrano una volatilità dei controlli in modalità strict 4.9× superiore (Cohen's d = 1.49).
Fix di Sintassi: Le transizioni immediatamente successive a un fix di sintassi portano un rischio di regressione del 21% superiore in modalità standard.
Timeline Pulite: Controintuitivamente, gli scenari che hanno mantenuto una sintassi valida durante tutto il processo ("clean" timelines) hanno avuto un tasso di regressione più alto (20.8%) rispetto a quelli che hanno lottato con errori di sintassi (12.1%).

Risultati Aggiuntivi

Auto-correzione: Il 36.6% delle regressioni in modalità standard si è auto-corretto entro una media di 1.2 iterazioni, suggerendo che il ciclo di feedback spesso cattura i propri errori.
Oscillazione: Il 28.5% degli scenari ha mostrato controlli oscillanti (passaggio, fallimento, poi di nuovo passaggio), particolarmente nelle configurazioni IAM.
Arresto Ottimale: L'Iterazione 3 è identificata come il punto di arresto ottimale, catturando l'83.1% del tasso di superamento (entro 0.3 punti percentuali dal picco) mantenendo il rischio di regressione gestibile.

Significato e Rivendicazioni

Il documento sostiene di fornire la prima prova empirica che la riparazione iterativa dell'IaC introduce regressioni di sicurezza, sebbene la gravità dipenda fortemente dalla metodologia di rilevamento. Gli autori affermano che, sebbene il "tasso conservativo e difendibile" di vere regressioni esclusive sia di circa il 3.3%, il fenomeno non è trascurabile ed è interamente mascherato dalle metriche cumulative-best utilizzate nei lavori precedenti.

Lo studio sottolinea che la ristrutturazione delle risorse è il driver principale della degradazione, non solo la strategia di prompting o la temperatura. I risultati motivano la progettazione di cicli di feedback consapevoli della sicurezza che:

Distinguano tra artefatti multi-risorsa e fallimenti esclusivi.
Implementino l' "ancoraggio della sicurezza" (security anchoring) per evitare che il modello rigeneri interi blocchi di risorse quando sono necessarie solo piccole correzioni.
Adottino un budget di iterazione di circa 3 iterazioni per bilanciare i guadagni di conformità rispetto ai rischi di regressione.
Utilizzino la volatilità dei controlli come segnale in tempo reale per interrompere o segnalare i cicli di riparazione.

Gli autori concludono che, sebbene la riparazione iterativa migliori la conformità complessiva, essa introduce una specifica classe di degradazione della sicurezza che richiede nuove metodologie di rilevamento e salvaguardie operative, specialmente data la natura dichiarativa e multi-risorsa dell'IaC.