SecGent usa base de fraquezas CWE para fazer LLMs gerarem código mais seguro sem perder funcionalidade

Modelos de linguagem geram com frequência código que funciona corretamente mas contém falhas de segurança clássicas — injeção, deserialização insegura, validação de entrada ausente — porque o objetivo de treinamento e as métricas de avaliação mais comuns priorizam corretude funcional, não ausência de vulnerabilidades. Ajuste fino voltado à segurança existe, mas é caro e nem sempre disponível para quem usa modelos de terceiros via API. O SecGent ataca o problema em tempo de inferência, sem tocar nos pesos do modelo.

A técnica funciona conectando a especificação da tarefa de programação a registros textuais relevantes do catálogo CWE (a enciclopédia padrão de classes de fraqueza de software mantida pela MITRE), fornecendo ao modelo orientação de segurança específica para aquele tipo de tarefa — sem depender de exemplos de código vulnerável ou corrigido recuperados de um banco de dados, que é a abordagem usual de RAG aplicado a segurança e que pode vazar padrões de código indesejados para a tarefa atual. Depois da geração inicial, testes funcionais e de segurança complementares validam a implementação, e o feedback da execução desses testes orienta um ciclo de reparo automático que tenta satisfazer os dois objetivos ao mesmo tempo, em vez de sacrificar um pelo outro — um risco real de prompts de segurança genéricos, que às vezes removem comportamento necessário da tarefa.

Avaliado no benchmark CWEval em cinco linguagens de programação, com quatro LLMs open-source e o Claude Sonnet 5.5, o SecGent superou quatro baselines de tempo de inferência (incluindo RAG tradicional e otimização de prompt). A métrica combinada funcional-segurança (FS@1) melhorou em média 15,5% sobre RAG nos modelos abertos, e chegou a 92,1% no Claude Sonnet 5.5 — superando o baseline AutoGen em 4,8 pontos e superando também o Claude Code com prompting voltado a segurança em mais de 6 pontos. O ciclo de reparo guiado por feedback adicionou até 6,7% de melhoria extra, recuperando principalmente funcionalidade perdida, não segurança.

O resultado é relevante porque geração de código por IA já é parte do fluxo normal de desenvolvimento de software em muitas equipes, e esse estudo confirma que mitigação de vulnerabilidades em tempo de inferência — sem fine-tuning, sem mudar o modelo usado — é viável e mensurável com uma fonte estruturada de conhecimento de segurança (CWE) em vez de exemplos de código recuperados. É também um lembrete de que funcionar e ser seguro são objetivos que competem entre si quando tratados ingenuamente, e que medir só um deles mascara o outro.