SESAA: agente de LLM evolui sozinho regras de análise estática para achar vulnerabilidades
Pesquisadores propõem o SESAA, um framework em que um agente LLM parte do zero e evolui iterativamente um conjunto de queries Joern (análise estática) com base apenas no feedback de um segundo LLM crítico, sem acesso a rótulos verdadeiros. No benchmark OWASP para Python, o sistema atinge F1 médio de 0,742, comparável às ferramentas tradicionais mais fortes, e detecta 10 de 19 CVEs reais em um piloto.
A análise estática tradicional depende de regras escritas manualmente por especialistas, o que cria uma defasagem crônica: novos frameworks, APIs e idiomas de código surgem mais rápido do que as regras de detecção conseguem ser atualizadas. O SESAA ataca esse problema invertendo o fluxo de trabalho: em vez de um humano escrever e manter queries Joern, um agente LLM gera e revisa essas queries iterativamente, usando como único sinal de feedback outro LLM que inspeciona o código sinalizado (e o não sinalizado) procurando falsos positivos e falsos negativos suspeitos — sem jamais ver o rótulo correto real.
O mecanismo técnico central é esse ciclo agente-crítico sem supervisão direta: o agente propõe uma regra, aplica-a ao código, e o crítico examina os resultados para inferir, por inspeção semântica, se parecem plausíveis como vulnerabilidades reais ou como ruído. Esse feedback orienta a próxima iteração da regra. O resultado final não é uma caixa-preta estatística, mas um conjunto de queries Joern executáveis e legíveis por humanos, que um engenheiro de segurança pode inspecionar, versionar e ajustar manualmente — uma propriedade importante para adoção em pipelines de SAST corporativos, que normalmente exigem auditabilidade.
O dado mais relevante do ponto de vista prático é o piloto em projetos reais: queries induzidas a partir do código disponível antes da introdução de uma vulnerabilidade conseguiram detectar 10 de 19 CVEs subsequentes, incluindo 9 que corresponderiam a regras escritas manualmente para aquele mesmo repositório depois do fato. Isso sugere que o padrão de código que antecede uma vulnerabilidade muitas vezes já contém sinais detectáveis por regras genéricas, e que um agente capaz de gerar regras automaticamente pode antecipar parte do trabalho que hoje só acontece reativamente, depois que o CVE é público.
Para quem decide sobre postura de segurança de software, o SESAA aponta para um futuro em que a manutenção de regras de SAST deixa de ser um processo manual e vira um processo contínuo e automatizado de descoberta e reparo — reduzindo a defasagem entre a criação de novas vulnerabilidades (por frameworks e padrões novos) e a capacidade das ferramentas de detectá-las, desde que a auditabilidade das regras geradas seja preservada.