🤖 AI

Secure Code Generation at Scale with Reflexion

Este artigo avalia a eficácia do prompting de reflexão no aumento da segurança do código gerado por cinco modelos de linguagem de grande escala ajustados por instrução, constatando que, embora os baselines zero-shot produzam código inseguro em 25-33% dos casos, um processo de reflexão de três rodadas melhora significativamente as métricas de segurança, com os ganhos mais substanciais ocorrendo na primeira rodada.

Autores originais: Arup Datta, Ahmed Aljohani, Hyunsook Do

Publicado 2026-06-08

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Arup Datta, Ahmed Aljohani, Hyunsook Do

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ê contratou uma equipe de programadores juniores muito talentosos e falantes (os modelos de IA) para escrever o código para o seu software. Você dá uma instrução simples, como "Construa uma página de login segura", e eles digitam furiosamente.

Este artigo faz uma pergunta simples, mas crítica: Só porque o código funciona, ele é realmente seguro? E, mais importante, se dissermos a eles: "Ei, você cometeu um erro, tente novamente", eles conseguem consertar?

Aqui está o detalhamento das descobertas deles usando analogias do cotidiano:

1. O Problema do "Primeiro Rascunho"

Os pesquisadores descobriram que, quando esses modelos de IA escrevem código pela primeira vez (chamado de "zero-shot"), é como um aluno fazendo uma prova sem estudar.

O Resultado: Aproximadamente 25% a 33% do código que eles escrevem já possui brechas de segurança imediatamente. É como entregar a planta de uma casa onde a porta da frente não tem tranca, ou as janelas são feitas de papel.
A Analogia: Pense nisso como um chef que é ótimo em fazer um bolo delicioso, mas vive esquecendo de colocar a tampa no pote de veneno que mantém ao lado do açúcar. O bolo tem um gosto bom (o código funciona), mas é perigoso para comer (o código é inseguro).

2. O Ciclo de "Reflexão" (A Segunda Chance)

Os pesquisadores não deixaram apenas os chefs servirem o bolo. Eles introduziram um processo chamado Reflexion.

Como funciona: Depois que a IA escreve o código, um scanner de segurança (um inspetor robô) verifica o código e diz: "Você deixou a porta dos fundos aberta" ou "Você usou uma tranca fraca". A IA então lê esse feedback, reflete sobre ele e reescreve o código. Eles fizeram isso até três vezes.
A Analogia: É como um professor corrigindo uma redação, circulando os erros e pedindo ao aluno que a reescreva.
O Resultado: Esta "segunda chance" funcionou maravilhas. A segurança do código saltou de cerca de 71% seguro para 79% seguro.
A Ressalva: A maior parte da melhoria aconteceu na primeira reescrita. Na segunda e terceira tentativas, a IA estava apenas polindo detalhes minúsculos. É como consertar a tranca da porta frontal imediatamente, mas depois passar as próximas duas horas tentando encontrar um grão de poeira na maçaneta.

3. A Dificuldade da "Linguagem"

Nem todas as linguagens de programação são igualmente difíceis para a IA lidar com segurança.

O Modo Fácil: Python foi a mais segura. É como pedir à IA para construir uma casa na árvore; a IA conhece bem as regras padrão.
O Modo Difícil: C e C# foram as mais perigosas. Essas linguagens são como construir uma usina nuclear; um erro minúsculo na fiação causa um derretimento. A IA teve mais dificuldades aqui.
O Meio Termo: Linguagens como Java, JavaScript e C++ ficaram em algum lugar entre esses dois extremos.

4. "Bugs Complicados" vs. "Bugs Óbvios"

Os pesquisadores observaram que tipo de erros a IA cometia.

Os Consertos Fáceis: A IA foi, na verdade, bastante boa em evitar erros "padronizados", como deixar uma senha codificada no texto ou deixar uma porta de entrada para hackers injetarem comandos. É como se a IA soubesse: "Ah, eu não deveria escrever a senha em um post-it".
Os Consertos Difíceis: A IA teve mais dificuldade com criptografia (encriptação) e erros de configuração. Estes são como tentar assar um bolo com uma reação química específica e complexa. Se a temperatura estiver fora por um grau, tudo falha. A IA frequentemente errava a matemática ou as configurações.

5. O Risco de "Regressão"

Um achado interessante foi que, às vezes, quando a IA tentava corrigir um erro, ela acidentalmente quebrava algo que estava funcionando bem.

A Analogia: Imagine que você está consertando uma torneira com vazamento. Você aperta a válvula, mas, ao fazer isso, acaba quebrando o cano atrás dela.
A Descoberta: A IA fez isso ocasionalmente, mas não o suficiente para anular os benefícios. O "Ganho Líquido" (consertos menos novos erros) ainda era positivo.

O Veredito Final

O artigo conclui que, embora a IA esteja ficando melhor em escrever código, ela ainda comete muitos erros de segurança na primeira tentativa. No entanto, se você der a ela a chance de revisar seu próprio trabalho e corrigi-lo uma ou duas vezes, você obtém um código significativamente mais seguro.

O conselho deles: Não espere perfeição na primeira tentativa. Em vez disso, construa um sistema onde a IA escreve o código, recebe um "boletim de segurança" e corrige os principais problemas imediatamente. Fazer isso uma ou duas vezes captura quase todos os benefícios; fazer isso dez vezes é apenas perda de tempo.

Resumo Técnico: Geração de Código Seguro em Escala com Reflexion

Definição do Problema
Embora os Grandes Modelos de Linguagem (LLMs) sejam amplamente adotados para redigir e refatorar código, a segurança do código gerado continua sendo uma preocupação crítica. Pesquisas anteriores estabeleceram que os LLMs frequentemente produzem código que é funcionalmente correto, mas inseguro, herdando vulnerabilidades de seus dados de treinamento. Os benchmarks de segurança existentes enfrentaram limitações, incluindo cobertura de linguagem estreita, dependência de conjuntos de dados de pequena escala e "contaminação por pistas" (cue contamination), onde prompts ou identificadores inadvertidamente vazam informações de vulnerabilidade, inflando as métricas de insegurança. Além verdade, a maioria das avaliações baseia-se em prompting de turno único (zero-shot), falhando em avaliar se estratégias iterativas de reflexão e revisão podem melhorar efetivamente os resultados de segurança. Há uma carência de avaliações sistemáticas de larga escala que utilizem benchmarks de alta cobertura e validade aprimorada para medir a eficácia da autocorreção iterativa na geração de código seguro.

Metodologia
Os autores realizaram uma avaliação de larga escala utilizando o benchmark Instruct Prime, uma versão corrigida do CyberSecEval que remove prompts de conformidade exigida e reduz a contaminação por pistas. O estudo envolveu os seguintes componentes:

Modelos: Cinco LLMs de código ajustados para instrução foram avaliados: Qwen2.5-Coder-32B, Codestral-22B, CodeLlama-34B, DeepSeek-Coder-33B e OpenCoder-8B.
Estratégias de Prompting:
- Baseline Zero-Shot ( $t_0$ ): Os modelos geraram código baseando-se apenas na descrição da tarefa, sem orientação de segurança.
- Prompting de Reflexão (Reflexion) ( $t_1, t_2, t_3$ ): Um loop iterativo de três rodadas onde o modelo recebe seu código anterior, os resultados de uma análise estática de segurança e dicas específicas sobre categorias de CWE (Common Weakness Enumeration) sinalizadas. O modelo é instruído a revisar o código para remover vulnerabilidades enquanto preserva a funcionalidade.
Avaliação de Segurança: O Insecure Code Detector (ICD), um conjunto de regras estáticas alinhadas ao CWE, foi utilizado para escanear todos os trechos de código gerados.
Métricas: O estudo introduziu três métricas para avaliar o desempenho iterativo:
- Reparo (Repair): A porcentagem de amostras anteriormente inseguras que se tornaram seguras na rodada seguinte.
- Regressão (Regression): A porcentagem de amostras anteriormente seguras que se tornaram inseguras na rodada seguinte.
- Ganho Líquido (NetGain): A diferença entre as taxas de Reparo e Regressão.
Pós-processamento: Para garantir uma avaliação justa, as saídas foram filtradas para incluir apenas "Código Completo". Saídas que não fossem código ou que fossem mistas foram marcadas como inseguras para evitar que os modelos contornassem as verificações de segurança gerando texto em vez de código.

Principais Contribuições

Avaliação de Larga Escala: O estudo fornece uma avaliação abrangente da geração de código seguro em cinco modelos, oito linguagens de programação e 50 categorias de CWE usando o benchmark validado Instruct Prime.
Análise de Reflexão Iterativa: É a primeira avaliação sistemática da autorreflexão para geração de código seguro em escala, testando se os modelos podem melhorar a segurança iterativamente através de três rodadas de revisão.
Métricas Abrangentes: O artigo vai além da simplicidade da acurácia ao reportar as métricas de Reparo, Regressão e Ganho Líquido, oferecendo uma visão matizada de como as estratégias iterativas melhoram a segurança sem introduzir novas vulnerabilidades.
Pacote de Replicação: Um pacote de replicação completo, incluindo prompts, logs de geração e artefatos de pontuação, está disponível para permitir auditoria e reuso.

Resultos

Insegurança de Baseline: No baseline zero-shot ( $t_0$ $t_{0}$ ), a insegurança é prevalente, com aproximadamente 25–33% dos programas gerados sendo inseguros.
- Variância de Linguagem: Python apresentou as maiores taxas de segurança (78–88%), enquanto C e C# mostraram as menores (55–67%).
- Variância de CWE: Vulnerabilidades de modelo (templated), como XSS (CWE-79), injeção de código (CWE-94) e segredos codificados (CWE-798), foram tratadas de forma confiável (taxas de segurança de 85–90%). Por outro lado, criptografia fraca (CWE-338) e bugs dependentes de configuração foram os mais difíceis de evitar, com taxas de segurança caindo para 10–35% em categorias específicas.
Impacto da Reflexão: Aplicar a estratégia de reflexão melhorou a acurácia média de geração segura de 70,74% em $t_0$ para 79,43% em $t_3$ .
- Retornos Decrescentes: Os maiores ganhos ocorreram na primeira rodada ( $t_1$ , +6,00 pontos percentuais). Rodadas subsequentes ( $t_2, t_3$ ) renderam melhorias menores (+1,66 e +1,03 pp, respectivamente).
- Desempenho dos Modelos: QwenCoder e Codestral mostraram as melhorias mais significativas (aprox. +11 pontos percentuais). O OpenCoder mostrou ganhos mais modestos.
- Regressões: Embora os reparos fossem comuns, rodadas tardias ocasionalmente introduziam regressões (1–2%), onde o código seguro era revisado para um código inseguro.
Estratégia Ótima: Os dados sugerem que uma a duas rodadas de reflexão capturam a maioria dos benefícios de segurança, com rodadas adicionais proporcionando retornos decrescentes.

Significância e Alegações
O artigo alega que a insegurança continua sendo um problema generalizado no código gerado por LLMs, com cerca de um quarto a um terço das saídas iniciais contendo vulnerabilidades. O estudo demonstra que o prompting de reflexão é um mecanismo eficaz e livre de treinamento (training-free) para reduzir significativamente essa taxa de insegurança. No entanto, os autores enfatizam que a reflexão não elimina o risco inteiramente; ela corrige primariamente os erros mais diretos e óbvios na primeira iteração.

Os autores concluem que, embora a reflexão iterativa melhore a segurança, os benefícios estão sujeitos a retornos decrescentes e ao risco de regressão. Eles propõem uma política prática: executar uma rodada de reflexão por padrão, continuar apenas para casos que permanecem inseguros e parar assim que o Ganho Líquido mostrar pouca melhoria ou quando as regressões se aproximarem do nível dos reparos. O estudo destaca que, embora os LLMs estejam melhorando, famílias específicas de vulnerabilidades (fraquezas criptográficas, autenticidade de dados) e linguagens de baixo nível (C, C#) permanecem desafios significativos que requerem investimento adicional em padrões seguros e dados de treinamento de alta qualidade.