💻 computer science

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

Este estudo empírico analisa 5.968 cenários iterativos de reparo de Infraestrutura como Código impulsionados por LLM para revelar que, embora regressões de segurança ocorram em até 13,8% dos casos sob detecção padrão, uma análise de modo estrito mais conservadora mostra uma taxa de degradação defensável de 3,3%, primariamente impulsionada pela reestruturação de recursos e mitigada ao interromper os reparos após a terceira iteração.

Autores originais: Benjamin Agyekum, Fabio Santos

Publicado 2026-08-14

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Benjamin Agyekum, Fabio Santos

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está construindo um castelo massivo e intrincado feito de blocos digitais. Este não é apenas um castelo qualquer; é a infraestrutura que sustenta a internet, seus aplicativos favoritos e serviços em nuvem. No mundo da engenharia de software, isso é chamado de Infraestrutura como Código (IaC). Em vez de clicar em botões em um menu, os engenheiros escrevem arquivos de texto (código) que dizem ao computador exatamente como construir esses castelos digitais. Recentemente, começamos a usar assistentes de IA superinteligentes, conhecidos como Modelos de Linguagem de Grande Escala (LLMs), para escrever esse código para nós. É como contratar um arquiteto robô que pode desenhar plantas em segundos.

Mas aqui está o problema: robôs cometem erros. Às vezes, as plantas que eles desenham têm brechas de segurança — como deixar a porta da frente escancarada ou esquecer de trancar o baú do tesouro. Para corrigir isso, usamos um "ciclo de feedback". Nós executamos um scanner de segurança (um inspetor digital) que verifica o trabalho do robô, aponta os erros e envia as más notícias de volta para o robô. O robô, então, tenta corrigir o código e o envia de volta para outra verificação. Esse ciclo se repete, esperando que o castelo fique mais seguro a cada rodada. A grande questão é: corrigir um problema acidentalmente quebra algo que já estava seguro? É como tentar remendar um furo em um barco, apenas para acidentalmente abrir um buraco no casco enquanto faz isso. Este artigo mergulha profundamente nesse exato cenário para ver se nossos ajudantes de IA estão realmente tornando as coisas mais seguras ou apenas fazendo uma bagunça.

O Dilema do Arquiteto Robô: Quando Consertos Quebram Consertos

Neste estudo, os pesquisadores Benjamin Agyekum e Fabio Santos decidiram brincar de detetive com um enorme conjunto de dados dessas tentativas de reparo por IA. Eles analisaram quase 6.000 cenários diferentes onde uma IA tentou construir ou consertar código de infraestrutura em nuvem. Eles observaram o que aconteceu ao longo de 5 rodadas de reparos, rastreando 30 verificações de segurança específicas (como "Os dados estão criptografados?" ou "O acesso está bloqueado?").

A principal descoberta deles é um pouco surpreendente: Sim, consertar coisas pode quebrar a segurança, mas não é tão assustador quanto parece à primeira vista.

Quando olharam para os números brutos usando uma forma "padrão" de contagem, descobriram que, em 13,8% das vezes, a IA conseguiu quebrar uma regra de segurança que estava funcionando anteriormente enquanto tentava consertar outra coisa. Isso parece muito, certo? Mas os pesquisadores perceberam que a maneira como estavam contando era um pouco complicada. Como o código geralmente envolve muitas partes diferentes (como vários cadeados digitais em um edifício), a IA pode consertar um cadeado, mas acidentalmente alterar o status de outro, mesmo que a segurança real não tenha sido verdadeiramente comprometida.

Quando mudaram para uma forma "estrita" de contagem — procurando apenas casos claros e inegáveis onde a segurança realmente piorou — o número caiu drasticamente para apenas 3,3% dos cenários. Isso sugere que a maioria dos "erros" eram apenas falhas de medição confusas causadas pela complexidade do código, e não desastres de segurança genuínos.

O "Porquê" e o "Como" da Quebra

Então, quando a IA realmente erra, o que está acontecendo? Os pesquisadores descobriram que o culpado é quase sempre a reestruturação de recursos. Imagine que o arquiteto robô decide reconstruir completamente uma parede em vez de apenas remendar uma rachadura. Ao fazer isso, ele pode esquecer de colocar a câmera de segurança de volta na nova parede. Isso aconteceu em 79% dos casos onde a segurança realmente regrediu.

Eles também notaram algo interessante sobre a "personalidade" dos modelos de IA. Um modelo (Mistral) parecia quebrar as coisas 17 vezes mais frequentemente do que outro (Gemini) ao usar o método de contagem padrão. No entanto, quando usaram o método estrito, nenhum dos modelos quebrou nada exclusivamente. Isso significa que o modelo "ruim" não estava criando mais buracos perigosos; ele estava apenas criando estruturas de código mais complexas que confundiam o método de contagem.

O Ponto Ideal: Quando Parar de Consertar

Uma das descobertas mais práticas é sobre quando parar. A IA continua tentando melhorar o código, mas ela para em algum momento? O estudo sugere que a 3ª iteração (a terceira vez que a IA tenta consertar o código) é o ponto ideal.

Até a 3ª tentativa, o código está cerca de 83,1% seguro.
Se você continuar até a 4ª ou 5ª tentativa, você mal ganha mais segurança (talvez 0,3% a mais), mas começa a aumentar o risco de quebrar as coisas novamente.

É como sintonizar um rádio: depois de certo ponto, girar o botão apenas aumenta o ruído sem encontrar uma estação mais clara.

A Luz no Fim do Túnel: Autocorreção

Aqui está a parte mais esperançosa da história. Os pesquisadores descobriram que, quando a IA realmente quebra uma regra de segurança acidentalmente, ela frequentemente se corrige sozinha! Cerca de 36,6% das vezes, a rodada seguinte de reparos corrige o erro que a própria IA cometeu. É como se o arquiteto robô percebesse: "Ops, eu tirei a porta errada", e a coloca de volta no próximo passo.

No entanto, eles também encontraram um efeito de "cabo de guerra". Cerca de 28,5% das vezes, as verificações de segurança oscilavam de um lado para o outro — passa, falha, passa, falha — como um pêndulo que não consegue decidir onde parar. Isso geralmente acontece com controles de acesso complexos, sugerindo que a IA ainda está tentando entender a melhor maneira de construir essas partes específicas.

A Conclusão

Este artigo nos diz que, embora o reparo iterativo por IA seja uma ferramenta poderosa, precisamos ter cuidado sobre como medimos seu sucesso.

Não entre em pânico com cada falha técnica: A maioria das aparentes quebras de segurança são apenas artefatos de medição confusos, não perigos reais.
Cuidado com grandes reestruturações: Se a IA começar a demolir seções inteiras de código para consertar um pequeno bug, é aí que a segurança tem mais chances de falhar.
Pare no três: Deixe a IA tentar três vezes para consertar o código e depois pare por aí. Continuar geralmente adiciona mais risco do que recompensa.
Use as ferramentas certas: Se você quiser ser super seguro, use uma forma de verificação "estrita" que ignore erros de múltiplas partes confusos, mas fique de olho nos alertas "padrão" para o caso de algo acontecer.

Em resumo, a IA é um aprendiz prestativo, mas precisa de um supervisor humano para saber quando parar de girar a chave, ou ela pode acabar apertando o parafuso com tanta força que quebra toda a máquina.

Resumo Técnico: O Conserto Quebra a Segurança? Um Estudo Empírico de Degradação de Segurança em Reparo de Infraestrutura como Código Impulsionado por LLM Iterativo

Declaração do Problema

Embora os loops de feedback iterativos — onde validadores como Checkov e terraform validate alimentam sinais de erro de volta para Grandes Modelos de Linguagem (LLM) para tentativas sucessivas de reparo — tenham se tornado o paradigma dominante para melhorar o Infraestrutura como Código (IaC) gerado por LLM, pesquisas anteriores basearam-se amplamente em métricas de melhor cumulativo. Essas métricas relatam a maior conformidade alcançada em todas as iterações, que são monotonicamente não decrescentes por construção. Consequentemente, a trajetória de segurança bruta por iteração nunca foi examinada no domínio de IaC.

Este estudo aborda o fenômeno da regressão de segurança: instâncias onde um controle de segurança anteriormente aprovado (especificamente controles do CIS Benchmark) falha após uma iteração de reparo destinada a corrigir outros problemas. Diferente dos estudos de reparo de código de propósito geral (ex: Shukla et al. [25], Chen et al. [7]) que focam em linguagens imperativas e contagens de vulnerabilidades, esta pesquisa investiga os desafios únicos de IaC. IaC é declarativo, e as verificações de segurança mapeiam para propriedades de configuração específicas no nível do recurso. Uma distinção crítica é que um único ID de verificação do Checkov pode se aplicar a múltiplos recursos dentro de uma única configuração, criando uma classe de ambiguidade de múltiplos recursos onde uma verificação pode passar para alguns recursos e falhar para outros simultaneamente. Essa ambiguidade complica a definição de uma "regressão" em IaC comparado ao código geral.

Metodologia

Os autores realizaram um estudo empírico em larga escala analisando 5.968 cronogramas de cenários do benchmark IaC-Eval. O design do estudo envolveu:

Configurações: 15 configurações experimentais distintas compreendendo duas configurações de Geração Aumentada de Recuperação (RAG) específicas de modelo (Gemini e Mistral) e nove configurações não-RAG agregadas de modelos (Zero-Shot, Few-Shot, Chain-of-Thought), cada uma executada em três temperaturas (0.1, 0.4, 0.7).
Processo: Cada cenário foi executado através de até 5 iterações de reparo. O pipeline gerou código Terraform, validou-o e enviou os erros de volta para o LLM.
Volume de Dados: A análise cobriu 4.440 transições de iteração onde os dados do Checkov estavam disponíveis tanto para os estados pré quanto pós-reparo.
Rastreamento: O estudo rastreou 30 IDs de verificação individuais do Checkov mapeados para controles do CIS AWS Foundations Benchmark em seis categorias de segurança (criptografia, controle de acesso, registro, rede, proteção de dados e outros).
Modos de Detecção: Para abordar a ambiguidade de múltiplos recursos, dois modos de detecção foram formalizados:
- Padrão (Inclusivo): Conta uma regressão se um ID de verificação aparece no conjunto de aprovados na iteração $i$ e no conjunto de falhas na iteração $i+1$ , independentemente de também ter passado para outros recursos.
- Estrito (Exclusivo): Conta uma regressão apenas se um ID de verificação foi exclusivamente aprovado (sem falhas) na iteração $i$ e exclusivamente falhou (sem aprovações) na iteração $i+1$ .
Análise de Causa Raiz: Os diffs de código foram classificados em quatro categorias mutuamente exclusivas: Reestruturação de Recursos, Desvio de Configuração, Remoção de Argumentos e Não Classificado.
Análise Estatística: O estudo utilizou testes Qui-quadrado, testes Mann-Whitney U, teste exato de Fisher e medidas de efeito de tamanho (Cramér's V, Cohen's d) com correção de Bonferroni para múltiplas comparações.

Principais Contribuições

Primeiro Estudo Empírico em Larga Escala: Este é o primeiro estudo a analisar a trajetória de segurança por iteração do reparo de IaC impulsionado por LLM iterativo, indo além das métricas de melhor cumulativo para detectar regressões de segurança.
Taxonomia de Regressão: Os autores derivam uma taxonomia de causas raízes de regressão, identificando a Reestruturação de Recursos como a causa dominante (79,0% no modo padrão).
Distinção de Modo de Detecção: O artigo formaliza a distinção Padrão vs. Estrito, demonstrando que a escolha do modo de detecção altera qualitativamente as conclusões sobre o desempenho do modelo e a distribuição de risco.
Quantificação do Trade-off Segurança-Corretude: O estudo quantifica a relação entre mudanças de código e degradação de segurança, mostrando que transições de regressão envolvem significativamente maior churn de código e volatilidade de verificação.
Orientação Acionável: O estudo fornece orientações específicas sobre orçamentos de iteração e escolhas de configuração, identificando a iteração 3 como o ponto de parada ideal e destacando as capacidades de autocorreção do loop de feedback.

Principais Resultados

RQ1: Frequência de Regressões

Modo Padrão: 13,8% dos cenários (24,8% das transições) exibiram pelo menos uma regressão de segurança.
Modo Estrito: Ao filtrar para falhas exclusivas e inequívocas, a taxa cai para 3,3% dos cenários (5,2% das transições).
Interpretação: A lacuna entre os modos padrão e estrito indica que aproximadamente 76% das aparentes regressões são artefatos de medição de múltiplos recursos, em vez de falhas exclusivas genuínas.

RQ2: Controles de Segurança Vulneráveis

Modo Padrão: Controle de Acesso domina (38,5%), impulsionado por verificações relacionadas ao IAM (ex: CKV_AWS_356, CKV_AWS_111).
Modo Estrito: A classificação se inverte. Rede (42,6%) e Criptografia (21,6%) tornam-se os riscos dominantes, enquanto o Controle de Acesso cai para 9,2%.
Implicação: Regressões de controle de acesso são amplamente artefatos de ambiguidade de múltiplos recursos (ex: um papel IAM passa enquanto outro falha), enquanto regressões de rede e criptografia representam falhas exclusivas genuínas.

RQ3: Fatores de Configuração

Lacuna de Modelo (Configurações RAG): No modo padrão, o Mistral mostrou uma taxa de regressão 17× maior que o Gemini. No entanto, essa lacuna desaparece inteiramente no modo estrito para configurações RAG, onde nem RAG+Gemini nem RA+Mistral produziram uma única regressão de cenário no modo estrito (0 de 1.297 e 0 de 929, respectivamente). Isso confirma que a lacuna foi devida à ambiguidade de múltiplos recursos, não a falhas de verificação exclusivas.
Efeito RAG: O RAG parece ter uma taxa de regressão mais alta no modo padrão, mas uma taxa menor (zero) no modo estrito em comparação com estratégias não-RAG. Isso sugere que o RAG gera estruturas de múltiplos recursos mais abrangentes (aumentando as contagens padrão), mas fornece melhor fundamentação para propriedades de segurança individuais (reduzindo falhas exclusivas).
Temperatura: A temperatura teve um efeito estatisticamente significativo, mas praticamente negligenciável (Cramér's V = 0,049).

RQ4: Trade-off Segurança-Corretude

Code Churn: Transições de regressão envolvem 2,6× mais code churn (linhas alteradas) e menor similaridade de texto em comparação com transições sem regressão.
Volatilidade de Verificação: Esta é o preditor mais forte de regressão. Transições de regressão mostram 4,9× mais volatilidade de verificação no modo estrito (Cohen's d = 1,49).
Correções de Sintaxe: Transições imediatamente após uma correção de sintaxe carregam um risco de regressão 21% maior no modo padrão.
Cronogramas Limpos: Contra-intuitivamente, cenários que mantiveram sintaxe válida durante todo o processo ("limpos") tiveram uma taxa de regressão maior (20,8%) do que aqueles que lutaram com erros de sintaxe (12,1%).

Descobertas Adicionais

Autocorreção: 36,6% das regressões do modo padrão se autocorrigiram dentro de uma média de 1,2 iterações, sugerindo que o loop de feedback frequentemente captura seus próprios erros.
Oscilação: 28,5% dos cenários exibiram verificações oscilantes (passando, falhando, passando novamente), particularmente em configurações de IAM.
Parada Ideal: A Iteração 3 é identificada como o ponto de parada ideal, capturando 83,1% da taxa de passagem (dentro de 0,3 pontos percentuais do pico) enquanto mantém o risco de regressão gerenciável.

Significância e Alegações

O artigo afirma fornecer a primeira evidência empírica de que o reparo iterativo de IaC introduz regressões de segurança, embora a severidade dependa fortemente da metodologia de detecção. Os autores afirmam que, embora a "taxa conservadora e defensável" de regressões exclusivas genuínas seja de aproximadamente 3,3%, o fenômeno não é desprezível e é inteiramente mascarado pelas métricas de melhor cumulativo usadas em trabalhos anteriores.

O estudo enfatiza que a reestruturação de recursos é o principal motor da degradação, não a estratégia de prompting ou a temperatura isoladamente. As descobertas motivam o design de loops de feedback conscientes de segurança que:

Distinguem entre artefatos de múltiplos recursos e falhas exclusivas.
Implementam "ancoragem de segurança" para evitar que o modelo regenere blocos inteiros de recursos quando apenas correções menores são necessárias.
Adotam um orçamento de iteração de aproximadamente 3 iterações para equilibrar ganhos de conformidade contra riscos de regressão.
Utilizam a volatilidade da verificação como um sinal em tempo real para interromper ou sinalizar loops de reparo.

Os autores concluem que, embora o reparo iterativo melhore a conformidade geral, ele introduz uma classe específica de degradação de segurança que requer novas metodologias de detecção e salvaguardas operacionais, especialmente dada a natureza declarativa e de múltiplos recursos do IaC.