Resumo Técnico: SoK: Geração de Código Seguro por IA

1. Declaração do Problema

A rápida adoção de Grandes Modelos de Linguagem (LLMs) e agentes de codificação para a geração de software deslocou a questão de segurança de "Um modelo pode produzir um trecho vulnerável?" para uma questão sistêmica mais ampla: "Qual progresso o campo fez, quais armadilhas persistem e como o código gerado pode ser tornado mais seguro na prática?"

As avaliações atuais de geração de código seguro por IA sofrem de um "ponto cego de conhecimento" crítico. A maioria dos benchmarks depende de métricas centradas no output (ex: vereditos de aprovação/falha de analisadores estáticos ou testes de exploração) que confundem modos de falha distintos. Um modelo pode falhar porque carece de conhecimento de segurança, porque conhece o princípio mas falha em aplicá-lo, porque aplica uma mitigação parcial, ou porque protege o código quebrando a funcionalidade necessária. As métricas existentes colapsam esses cenários em um único veredito, obscurecendo os motivos de falha ao nível do mecanismo e dificultando o desenvolvimento de remédios direcionados. Além disso, as avaliações frequentemente priorizam verificações estáticas de nível de função e de um único CWE, em vez de segurança de nível de aplicação executável condicionada à correção funcional.

2. Metodologia: O Framework KAUGE

Para abordar essas lacunas, os autores introduzem o KAUGE (Knowledge–Actuation Unified Gap Evaluation), um framework centrado em princípios que decompõe a geração de código seguro por IA em três camadas distintas:

• Camada 1: Conhecimento (Compreensão de Linguagem Natural): Mede se os modelos entendem Princípios de Codificação Segura (SCPs) como conceitos de linguagem natural. Esta camada avalia a capacidade de um modelo de reconhecer, raciocinar sobre e explicar SCPs (ex: a partir dos catálogos OWASP e CERT) através de quatro dimensões: declarativa (o que a regra estabelece), causal (por que violações criam vulnerabilidades), procedural (como aplicar a regra) e contextual (quando a regra é relevante).
• Camada 2: Atuação (Geração ao Nível de Código): Mede se os modelos traduzem seu entendimento em código funcional e resistente a explorações. Esta camada utiliza benchmarks executáveis (CWEval para funções isoladas e BaxBench para aplicações web completas) para testar se o código gerado satisfaz as especificações funcionais e bloqueia explorações específicas.
• Camada 3: Gap (Diagnóstico ao Nível de Mecanismo): Analisa a divergência entre Conhecimento e Atuação. Determina se o código bem-sucedido implementa o mecanismo defensivo específico sugerido pelos SCPs relevantes. Esta camada categoriza os resultados em:
  • Sucesso Principiado: Seguro e em conformidade com a defesa mapeada.
  • Seguro por Outros Meios: Seguro, mas via um mecanismo fora da fórmula mapeada.
  • Conforme, mas Vulnerável: Parece seguir o princípio, mas permanece explorável devido a uma subdeterminação abstrata.
  • Falha de Atuação: Funcional e explorável, sem aplicação de princípio relevante.

Configuração Experimental:
O estudo avalia modelos e intervenções nestas camadas usando:

• Modelos: Qwen2.5-14B-Instruct (backbone de pesos abertos), GPT-5.1-Codex-Mini (referência proprietária) e variantes com ajuste fino de segurança (SafeCoder) e aprendizado por reforço (PurpCodeRL).
• Intervenções: Prompting consciente de segurança, Crítica e Melhoria Recursiva (RCI) e andaime agêntico (Codex Scaffold).
• Artefatos: Um benchmark de Compreensão de Linguagem Natural (NLU) com 6.382 perguntas verificadas derivadas de 456 regras OWASP/CERT; um mapeamento de fórmula de defesa de exploração-para-SCP; e um juiz de conformidade de SCP.

3. Resultados Principais

Conhecimento (Camada 1)

Os sistemas atuais demonstram uma forte compreensão de linguagem natural dos princípios de codificação segura. As pontuações nos catálogos OWASP e CERT estão significativamente acima do acaso (frequentemente >90% para OWASP, >86% para CERT).

• Achado: O ajuste fino de segurança (SafeCoder, PurpCodeRL) não melhora significamente as pontuações de reconhecimento de linguagem natural em comparação aos modelos base.
• Fraqueza: O raciocínio causal em relação a regras de baixo nível de C/C++ (CERT) continua sendo um ponto de estresse, com pontuações mais baixas em comparação com regras de alto nível orientadas para a web (OWASP).

Atuação (Camada 2)

Apesar das altas pontuações de conhecimento, a atuação ao nível de código é substancialmente menor.

• Correlação: A compreensão de SCP em linguagem natural é um preditor estatisticamente forte dos resultados ao nível de código (correção funcional, segurança e correção conjunta), particularmente ao nível de função.
• Modos de Falha: As falhas dividem-se entre código que não atende às especificações funcionais e código que é funcional, mas explorável. Na escala de aplicação, a funcionalidade é frequentemente a restrição limitante; muitos sistemas falham em produzir um backend executável antes que a segurança possa ser testada.
• Impacto da Intervenção:
  • Prompting: O prompting consciente de segurança ajuda os modelos a aplicar defesas em códigos que já estão próximos do correto, mas pode levar à "sobre-atuação" (quebrar a funcionalidade para satisfazer a segurança).
  • Treinamento: O ajuste fino de segurança não se transfere automaticamente para um comportamento executável robusto; pode enfraquecer a competência de implementação geral.
  • Andaime Agêntico: Fornecer acesso ao sistema de arquivos e ambientes de execução (Codex Scaffold) produz as melhores melhorias, sugerindo que a geração segura é, em parte, um problema de construção de software.

O Gap (Camada 3)

Existe um significativo "Gap de Conhecimento–Atuação". Os modelos muitas vezes conhecem o princípio relevante, mas falham em traduzi-lo para a fronteira de implementação correta.

• Diagnóstico: O gap não é aleatório.
  • Conforme, mas Vulnerável: Os modelos frequentemente implementam princípios abstratos (ex: validação de entrada) mas perdem detalhes específicos do sink (ex: falha ao verificar caracteres CR/LF em HTTP response splitting).
  • Seguro por Outros Meios: O código pode bloquear explorações via padrões de framework ou middleware em vez da defesa específica mapeada, levando a falsos negativos nas verificações de conformidade.
  • Falha de Atuação: O modelo gera código funcional que ignora o princípio relevante inteiramente (ex: interpolação direta de entrada do usuário).

4. Principais Contribuições

1. Sistematização: O artigo organiza o campo da geração de código seguro por IA através de pontos de intervenção (direcionamento de entrada, treinamento, geração restrita, feedback pós-geração) e sua dependência de conhecimento de segurança.
2. Framework KAUGE: Introduz um framework de medição de três camadas (Conhecimento, Atuação, Gap) que separa o que um sistema sabe, o que ele produz e se a produção atua a prática de segurança pretendida.
3. Achados Empíricos: Demonstra que, embora os modelos possuam amplo conhecimento de codificação segura, um gap substancial permanece na tradução desse conhecimento em código funcional e seguro. Identifica que o ajuste fino de segurança não fecha este gap e que o andaime agêntico melhora a atuação ao fortalecer a construção de software.
4. Insights Diagnósticos: Revela que as métricas padrão de aprovação/falha escondem modos de falha críticos, incluindo trade-offs entre funcionalidade-segurança, compreensão causal fraca e comportamentos de "conforme, mas vulnerável".

5. Significância e Caminhos Futuros

O artigo argumenta que o campo se moveu além de simplesmente expor os modelos a mais conhecimento de segurança; o gargalo central agora é a tradução do princípio de segurança para um programa seguro. Os autores propõem cinco caminhos concretos à frente:

1. Feedback Executável: Ir além de verificações estáticas para loops de feedback onde agentes recebem falhas de exploração e falhas de conformidade de SCP como sinais de reparo, otimizando para resultados conjuntos de funcionalidade-segurança.
2. Princípios Baseados em Sinks: Mudar de lembretes genéricos de segurança para orientação de implementação consciente de sinks (ex: padrões de consulta parametrizada específicos para SQL, canonicalização para path traversal) que correspondam à granularidade da exploração.
3. Injeção de Princípio Preservadora de Funcionalidade: Garantir que o prompting guiado por princípios identifique regiões de código mínimas para mudança para evitar a sobre-correção que quebra contratos funcionais.
4. Treinamento Baseado em Mecanismos: Treinar modelos na atuação causal — conectando mecanismos de vulnerabilidade às menores edições seguras que preservam a funcionalidade — em vez de apenas memorização de texto de regras.
5. Avaliação Consciente de Princípios e Explorações: Adotar pacotes de avaliação que relatem correção funcional, segurança conjunta e conformidade de SCP para distinguir entre diferentes tipos de sucesso e falha.

Em conclusão, o artigo postula que a geração de código seguro não é meramente um problema de aquisição de conhecimento, mas um problema de entrega. O futuro do campo reside em otimizar os mecanismos que vinculam os princípios de segurança conhecidos às regiões de código corretas, fronteiras de API e comportamentos executáveis.