WeSCE: um benchmark para medir se a IA piora a segurança do seu código sem avisar
O WeSCE mede 'security drift' — a degradação silenciosa da postura de segurança de um código quando um LLM faz edições pedidas apenas por objetivos funcionais, sem requisito de segurança explícito. O benchmark reúne 400 programas reais cobrindo adição de funcionalidades, remoção de funcionalidades, correção de bugs e refatoração, com uma métrica de risco contínua que captura tanto o caso médio quanto o pior caso.
A premissa do WeSCE é simples e desconfortável: na maior parte do uso real de assistentes de codificação por IA, o desenvolvedor pede 'adiciona esse endpoint' ou 'corrige esse bug', não 'adiciona esse endpoint de forma segura'. O requisito de segurança fica implícito — e os autores querem medir sistematicamente o que acontece com a postura de segurança do código quando esse requisito não é dito.
Tecnicamente, o benchmark parte de 400 programas executáveis derivados de código real, submetidos a quatro tipos de tarefa — adicionar funcionalidade, remover funcionalidade, corrigir bug, refatorar — via LLM, sem instrução de segurança na tarefa. Em vez de simplesmente contar vulnerabilidades antes e depois, os autores constroem uma representação de risco contínua que agrega diferentes sinais de vulnerabilidade em uma métrica única, e definem 'drift' em três dimensões: variação do risco médio, variação da severidade do pior caso, e mudança na distribuição de tipos de vulnerabilidade — uma forma de capturar tanto 'o código ficou um pouco pior em média' quanto 'o código ganhou um buraco crítico que não existia antes', que são problemas operacionalmente diferentes.
A página pública do paper não detalha os números por modelo testado — isso está no PDF completo, ao qual não tivemos acesso direto — mas a proposta metodológica em si já é o ponto relevante: hoje a maioria das avaliações de segurança de código gerado por IA olha para tarefas que já pedem código seguro por definição, não para o caso muito mais comum de edição incremental de uma base de código existente sem qualquer menção a segurança.
Na prática, isso é diretamente relevante para qualquer time que usa Copilot, Cursor, Claude Code ou similares no dia a dia de manutenção de código — que é a esmagadora maioria do uso desses assistentes, mais do que geração de código do zero. Um benchmark que isola esse cenário dá aos times de AppSec uma forma de comparar objetivamente se um modelo específico introduz regressões de segurança em tarefas cotidianas, algo que revisão manual de PR dificilmente detecta de forma sistemática.