Resumo Técnico: DualGauge

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) e agentes de codificação baseados em LLM são cada vez mais utilizados para gerar código a partir de especificações em linguagem natural. Embora a correção funcional tenha se tornado o critio dominante para avaliar esses sistemas, ela é insuficiente para garantir software implantável. Pesquisas anteriores indicam que assistentes de codificação de IA frequentemente geram código inseguro, e desenvolvedores costumam aceitar essas sugestões mantendo a confiança em sua segurança.

Os frameworks de avaliação existentes sofrem de duas limitações primárias:

1. Isolamento de Métricas: Benchmarks funcionais (ex: HumanEval, LiveBench) e benchmarks de segurança (ex: SecurityEval, CodeLMSec) tipicamente avaliam correção e segurança de forma isolada ou em conjuntos de dados diferentes. Um programa que passa em testes funcionais, mas contém vulnerabilidades, ou vice-versa, não é útil.
2. Desafios do Oráculo de Avaliação: A avaliação de segurança não pode depender apenas da correspondência exata de saída. Como ilustrado por exemplos de travessia de diretórios (path-traversal), uma implementação segura e uma vulnerável podem produzir saídas e códigos de saída idênticos em entradas adversariais. A distinção reside frequentemente no rastro de execução (ex: se um arquivo foi acessado antes de uma verificação falhar), exigindo raciocínio semântico sobre o comportamento em tempo de execução, em vez de uma simples comparação de saída.
3. Limitações de Contexto: A maioria dos benchmarks depende de completude de código, contexto de repositório ou scaffolding de framework, negligenciando a geração baseada apenas em especificação, onde um modelo deve implementar uma função a partir de uma descrição em linguagem natural isoladamente.

Metodologia: DualGauge e DualGauge-Bench

Os autores apresentam o DualGauge, um framework totalmente automatizado para a avaliação conjunta de segurança e funcionalidade na geração de código baseada apenas em especificação, suportado pelo DualGauge-Bench.

DualGauge-Bench

Este é um benchmark independente de linguagem composto por 307 tarefas de codificação.

• Design de Tarefa: Cada tarefa consiste em uma especificação de linguagem natural sem trechos de código, assinaturas de funções ou restrições específicas de linguagem.
• Testes Pareados: Cada especificação é pareada com dois conjuntos de testes derivados da mesma instrução (prompt):
  • Testes Funcionais: Guiados por análise de valor limite e particionamento de classe de equivalência para verificar a correção comportamental.
  • Testes de Segurança: Guiados pelos princípios OWASP e CERT para verificar a ausência de comportamentos inseguros (ex: falhas de validação de entrada, problemas de controle de acesso).
• Cobertura: O benchmark abrange sete domínios de funcionalidade e 90 categorias de CWE (Common Weakness Enumeration), cobrindo tarefas intraprocedurais e interprocedurais.
• Construção: Os prompts foram curados de conjuntos de dados existentes (CodeGuard+, SecurityEval, Purple Llama CyberSecEval) e convertidos para especificações puras. Os conjuntos de testes foram criados via um processo de co-criação humano-LLM, onde LLMs propuseram candidatos e avaliadores humanos validaram e estenderam os mesmos.

Sistema DualGauge

O sistema opera em quatro fases para automatizar o pipeline de avaliação:

1. Geração de Amostra: O LLM ou agente alvo gera $k$ candidatos de código para uma determinada especificação.
2. Execução Agêntica: Um executor guiado por LLM executa os candidatos em um ambiente isolado. Ele classifica falhas em problemas de ambiente, script ou código. Ele repara problemas de ambiente e script (ex: pacotes ausentes, erros de invocação), mas não altera o código candidato em si. Isso garante que o programa seja executável sem corrigir artificialmente a lógica do modelo.
3. Avaliação de Tempo de Execução Baseada em LLM:
   • Oráculo Funcional: Utiliza correspondência exata de saída contra as saídas esperadas.
   • Oráculo de Segurança: Utiliza um LLM para realizar julgamento semântico. Ele analisa o código candidato, as saídas de execução e os rastros de cobertura contra comportamentos de segurança esperados. Se o código utiliza bibliotecas desconhecidas, um modelo de resolução com capacidade de busca na web recupera a documentação para auxiliar a avaliação. Esta etapa determina se o código implementou uma defesa genuína ou se apenas falhou por acidente.
4. Agregação de Resultados: Computa métricas incluindo taxa de passagem funcional ($PR$), taxa de passagem segura ($SPR$) e a métrica conjunta secure-pass@k (a probabilidade de uma única amostra ser tanto funcionalmente correta quanto segura).

Principais Resultados

Os autores avaliaram 10 LLMs representativos (incluindo as famílias GPT-5, Claude Opus/Sonant, Llama, Qwen e Gemma) em Python, C++ e JavaScript, bem como 3 sistemas de codificação agênticos (Codex, OpenHands, Claude Code).

1. A Correção Funcional Superestima a Confiabilidade

Mesmo os modelos mais fortes alcançaram uma taxa de passagem funcional de quase 39% em tarefas Python, mas a taxa de sucesso conjunta de segurança-funcionalidade (secure-pass@1) permaneceu abaixo de 15% em todas as linguagens. Isso indica que a correção funcional é um pobre substituto (proxy) para a geração de código seguro.

2. Fatores do Lado do Modelo Não Melhoram a Performance Conjunta de Forma Confiável

O estudo analisou quatro fatores: escala, pensamento estendido (extended thinking), quantização e especialização em instrução/código.

• Escala: O aumento do tamanho do modelo melhorou a fluência funcional, mas a cobertura de segurança estagnou muito antes dos maiores tamanhos.
• Pensamento Estendido e Especialização: Estes fatores deslocaram as métricas funcionais e de segurança de formas diferentes dependendo da família do modelo e não melhoraram de forma confiável a métrica conjunta.
• Conclusão: A geração de código seguro e correto não emerge simplesmente de uma capacidade de codificação mais forte; ela requer a aplicação consistente de conhecimento de segurança em todos os requisitos.

3. Sistemas Agênticos Não Oferecem Vantagem

O scaffolding iterativo por agentes de codificação (Codex, OpenHands, Claude Code) não ofereceu vantagem sobre a geração direta para tarefas de especificação única.

• Mecanismo de Falha: Os agentes gastaram esforço significativo em overhead orientado ao repositório (ex: listar diretórios, buscar arquivos de configuração), o que não gerou sinal em um espaço de trabalho vazio.
• Ciclo de Feedback: Os agentes frequentemente dependiam de testes autogerados em vez de benchmarks de verdade fundamental (ground-truth). Defesas parciais que passavam nos testes internos do agente, mas falhavam nos testes de segurança do benchmark, não eram revisadas. Consequentemente, os agentes herdaram os mesmos modos de falha da geração direta sem fechar a lacuna de cobertura.

4. Modos de Falha

• Falhas Funcionais: Concentraram-se no limite do contrato de saída (ex: estrutura JSON incorreta, CLI vs. serviço incorreto), não em erros algorítmicos.
• Falhas de Segurança: Caracterizadas por defesas parciais. Os modelos frequentemente implementavam proteções (regex, verificações de tipo) que pareciam razoáveis, mas falhavam em cobrir o vetor de ataque específico ou eram aplicadas no nível de abstração errado.
• Lacuna Conjunta: Um programa poderia passar em testes funcionais sendo inseguro, ou passar em alguns testes de segurança enquanto falhava em outros. Apenas o benchmarking conjunto expôs de forma confiável essas falhas "silenciosas".

Significância e Alegações

O artigo afirma apresentar o primeiro framework totalmente automatizado para avaliar conjuntamente segurança e funcionalidade na geração de código baseada apenas em especificação. Sua significância reside em:

1. Revelar a Lacuna: Demonstrar que os modelos e agentes de estado da arte atuais lutam para satisfazer correção e segurança simultaneamente, com taxas de sucesso conjuntas permanecendo criticamente baixas (<15%).
2. Mudança Metodológica: Argumentar que a avaliação de segurança requer raciocínio semântico sobre rastros de execução em vez de correspondência de saída, e que os benchmarks devem parear testes funcionais e de segurança para a mesma especificação.
3. Limitações de Agentes: Mostrar que o refinamento de múltiplos turnos e o uso de ferramentas ainda não superam automaticamente o desafio central de produzir código seguro quando não há um código base existente ou um executor de testes para guiar o agente.
4. Padrão de Benchmark: Fornecer um benchmark reutilizável e independente de linguagem (DualGauge-Bench) que vai além da completude de código para testar a habilidade fundamental dos modelos de traduzir intenção em linguagem natural em código seguro e correto.

Os autores concluem que a geração de código segura exige a aplicação consistente do conhecimento de segurança em todo o espaço de requisitos, uma capacidade que os modelos e agentes atuais ainda não dominaram. Eles enfatizam que seus resultados são estimativas escaláveis de benchmark e que a revisão humana de segurança continua sendo necessária.