Combinar código-fonte, AST e grafo de fluxo de controle melhora detecção de vulnerabilidades por LLM em 5 pontos de F1

Detecção automatizada de vulnerabilidades em código C é um problema antigo em segurança de software: ferramentas de análise estática clássicas trocam precisão por escalabilidade e têm dificuldade com padrões de vulnerabilidade complexos que dependem de contexto. LLMs aplicados a essa tarefa trouxeram ganhos, mas a maioria das abordagens usa apenas uma representação do código (geralmente o texto-fonte bruto), assumindo implicitamente que essa representação é igualmente adequada para todo tipo de vulnerabilidade — uma suposição que o artigo testa e refuta empiricamente.

Os autores comparam sistematicamente três representações de entrada para LLMs de detecção: código-fonte bruto, Árvore de Sintaxe Abstrata (AST, que captura estrutura sintática) e Grafo de Fluxo de Controle (CFG, que captura caminhos de execução possíveis). A análise empírica mostra que cada representação tem vantagem para classes diferentes de vulnerabilidade — por exemplo, vulnerabilidades mais ligadas a fluxo de execução tendem a ser mais visíveis via CFG, enquanto outras são mais detectáveis em texto bruto ou AST — confirmando que nenhuma representação única é suficiente de forma geral.

Com base nisso, o RALE (Representation-Aware Logical Ensemble) integra LLMs especializados, cada um treinado sobre uma representação diferente, através de regras lógicas explícitas combinadas com votação por maioria, em vez de simplesmente concatenar as representações como entrada de um único modelo. Modelos de representação única atingem até 73% de F1-score isoladamente; o ensemble integrado chega a 78%, com ganhos correspondentes também em acurácia, precisão e recall — uma melhora consistente, embora não dramática, que os autores atribuem especificamente à complementaridade entre representações, não apenas ao efeito genérico de usar um ensemble.

O resultado reforça um ponto prático para quem constrói ou avalia ferramentas de detecção de vulnerabilidade assistidas por LLM: a escolha de como representar o código para o modelo não é um detalhe de engenharia neutro, mas afeta diretamente quais classes de falha o sistema consegue ou não enxergar. Para equipes de AppSec avaliando ferramentas desse tipo, é um lembrete de que uma única ferramenta otimizada para uma representação de código provavelmente tem pontos cegos sistemáticos em classes específicas de vulnerabilidade, e que combinar abordagens complementares — mesmo que de forma simples, como votação — pode fechar parte dessa lacuna sem precisar de um modelo maior.