Resumo Técnico: ALIBI - Ataques Agênticos Adaptativos contra Detectores de Vulnerabilidades Baseados em LLM via Comentários de Código Adversários

Declaração do Problema

À medida que os Grandes Modelos de Linguagem (LLMs) são cada vez mais implantados para tarefas sensíveis à segurança, como detecção de vulnerabilidades e revisão de código, eles dependem fortemente do contexto de linguagem natural incorporado no código-fonte (ex: comentários, documentação, contratos de API) para raciocinar sobre a intenção do programa e verificar alegações de segurança. Essa dependência cria uma superfície de ataque anteriormente inexplorada: comentários de código-fonte adversários.

Diferente dos ataques tradicionais que modificam o código executável para ocultar vulnerabilidades, este artigo investiga um modo de "falha de raciocínio". O problema central é se um adversário pode sintetizar uma nova implementação, genuinamente vulnerável, de uma tarefa de codificação e inserir estrategicamente alegações de segurança semanticamente coerentes, porém falsas, nos comentários do código-fonte. Esses comentários visam convencer o detector baseado em LLM a anular sua análise correta do código executável e aceitar a alegação falsa, classificando um programa vulnerável como benigno sem alterar o comportamento do programa ou a própria vulnerabilidade.

Metodologia: O Framework ALIBI

Os autores apresentam o ALIBI (Adaptive Agentic Attacks on LLM-Based Vulnerability Detectors via Adversarial Code Comments), um framework de ataque automatizado, adaptativo e de caixa-preta. O framework opera através de um pipeline de três fases:

1. Síntese de Código:

   • O atacante recebe uma tarefa de codificação em linguagem natural derivada de commits reais de correção de vulnerabilidades (especificamente desreferência de ponteiro nulo em C/C++, CWE-476).
   • Um modelo atacante (QWEN3.6-27B-FP8) sintetiza uma implementação funcional que contém intencionalmente uma desreferência de ponteiro nulo alcançável.
   • A implementação é validada para garantir que compile e passe na suíte de testes existente do repositório, garantindo que o ataque atinja um código que sobreviveria aos controles padrão de desenvolvimento.

2. Inicialização Guiada pelo Raciocínio:

   • O código vulnerável é enviado ao detector alvo.
   • Se o detector identificar corretamente a vulnerabilidade, o atacante analisa o traço de raciocínio do detector para identificar a evidência específica que sustenta o veredito de "vulnerável".
   • O atacante então fabrica uma alegação de segurança não verificável visando a lacuna no raciocínio do detector (ex: alegando que um invariante externo garante a segurança do ponteiro).
   • Este comentário inicial é gerado usando uma de 10 estratégias de apresentação, variando de notas simples (NOTE, USR) a alegações autoritárias citando ferramentas externas (TOOL_COVERITY, TOOL_CLANGSA, TOOL_FRAMA), grafos de chamada (CALL_GRAPH) ou análises de segurança passo a passo (COT).

3. Refinamento Adaptativo:

   • Se o comentário inicial falhar em inverter o veredito, o ALIBI entra em um loop de refinamento iterativo (até 5 rodadas).
   • O atacante usa o feedback do detector (veredito e raciocínio) para refinar o conteúdo e o posicionamento do comentário.
   • Este processo continua até que o veredito do detector mude para "Benigno" ou o orçamento de consultas seja esgotado.

Construção do Benchmark:
Os autores construíram um benchmark transformando 184 commits reais de correção de vulnerabilidades (do dataset MegaVul) em tarefas de codificação. Após filtrar por sucesso de compilação, passagem na suíte de testes e verificação independente da vulnerabilidade injetada, o benchmark final consiste em 125 instâncias validadas de desreferência de ponteiro nulo.

Contribuições Principais

1. Identificação de uma Nova Superfície de Ataque: O artigo identifica que comentários de código-fonte não executáveis podem ser usados para manipular detectores de vulnerabilidade baseados em LLM, explorando um "prior de confiança em comentários" onde os detectores atribuem peso de evidência indevido a alegações de segurança plausíveis, mas não verificadas.
2. Framework ALIBI: O design de um framework de ataque de caixa-preta adaptativo que gera comentários adversários semanticamente personalizados e os refina iterativamente usando o feedback do detector.
3. Benchmark Inédito: Um benchmark que transforma commits de correção de vulnerabilidades em tarefas de codificação para avaliar detectores em implementações vulneráveis recém-sintetizadas, em vez de código vulnerável histórico.
4. Avaliação Abrangente: Avaliação do ALIBI contra quatro detectores representativos baseados em LLM (OPENVUL, VULNLLM-R, VUL-RAG, VULTRIAL) e várias estratégias de defesa.
5. Análise de Defesa: Uma avaliação mostrando que defesas ao nível de prompt são limitadas, enquanto o isolamento arquitetural e a sanitização pré-detector oferecem resiliência substancial.

Resultados Experimentais

Eficácia do Ataque (RQ1)

O ALIBI alcançou taxas de sucesso extremamente altas em todos os quatro detectores avaliados:

• OPENVUL: 97,4% de Taxa de Sucesso de Ataque (ASR) (112/115 casos).
• VULNLLM-R: 91,2% ASR (103/113 casos).
• VUL-RAG: 95,5% ASR (106/111 casos).
• VULTRIAL: 100,0% ASR (105/105 casos).

Os ataques tiveram sucesso ao substituir o raciocínio correto do detector por evidências externas fabricadas (ex: "Frama-C verificado", "Construtor AST garante") que o detector não conseguia verificar a partir do código visível.

Estratégia de Apresentação (RQ2)

A eficácia do ataque dependeu fortemente do estilo de apresentação:

• Mais Eficaz: COT (Cadeia de Pensamento/Chain-of-Thought) alcançou o maior ASR (81,1%). Estratégias que invocavam evidência externa autoritária (ex: TOOL_COVERITY, CALL_GRAPH, TOOL_FRAMA) também foram altamente eficazes (>70% ASR).
• Menos Eficaz: Estratégias que se assemelham a notas informais de desenvolvedores (USR, ASSERT, FAKE_TEST) tiveram desempenho inferior à estratégia baseline NOTE, pois os detectores as tratavam explicitamente como menos confiáveis.

Eficiência do Ataque (RQ3)

• Diversidade: Nenhum estilo de apresentação único cobria todas as vulnerabilidades. Um portfólio de estratégias diversas (ex: COT + TOOL_COVERITY + TOOL_FUZZER) foi necessário para maximizar a cobertura.
• Refinamento: O refinamento adaptativo melhorou significativamente as taxas de sucesso. Aproximadamente 30 consultas ao detector foram suficientes para atingir >90% de cobertura em todos os sistemas.

Avaliação de Defesa (RQ4)

• Mitigações ao Nível de Prompt (D1, D2): Instruir o modelo a tratar comentários como não confiáveis forneceu proteção limitada. Os atacantes conseguiram se adaptar direcionando o raciocínio do modelo mesmo quando o modelo reconhecia que o comentário era não confiável.
• Isolamento Arquitetural (D3): Executar uma análise de baseline apenas de código em uma chamada separada antes de introduzir os comentários melhorou substancialmente a robustez (ex: reduzindo o ASR para 0% no VULNLLM-R), embora tenha sido menos eficaz em sistemas de debate de múltiplos estágios como o VULTRIAL.
• Sanitização Pré-Detector (D4): Filtrar comentários antes da inferência (removendo alegações não verificáveis) forneceu a proteção mais forte, reduzindo o ASR para abaixo de 3% em todos os sistemas.

Generalização (RQ6)

O framework foi testado em vulnerabilidades de Use-After-Free (UAF) (CWE-416). O ataque generalizou com sucesso, alcançando >95% de ASR em três dos quatro detectores, confirmando que a vulnerabilidade reside no mecanismo de raciocínio em relação a alegações externas, e não apenas no tipo específico de bug.

Significância e Alegações

O artigo alega que os atuais detectores de vulnerabilidade baseados em LLM possuem uma fraqueza fundamental: eles carecem da capacidade de distinguir rigorosamente entre evidências no código e alegações plausíveis, mas não verificáveis, em linguagem natural.

• Prior de Confiança: Os detectores exibem um "prior de confiança em comentários", onde deferem a alegações de segurança atribuídas a autoridades externas (analisadores estáticos, invariantes de framework), mesmo quando essas alegações não podem ser verificadas a partir do código-fonte enviado.
• Implicação de Design: Os autores argumentam que a robustez à documentação de software adversária deve ser um objetivo primário de design. Eles concluem que o isolamento arquitetural e a sanitização pré-detector são necessários para desacoplar o contexto de linguagem natural das evidências do programa, em vez de depender apenas de engenharia de prompt.
• Escopo: O trabalho é estruturado como uma avaliação de robustez usando um benchmark reproduzível, destacando um modo de falha específico na integração de LLMs em fluxos de trabalho de segurança. Não pretende resolver o problema, mas sim motivar designs conscientes de segurança que calibrem cuidadosamente a confiança entre o contexto de linguagem natural e as evidências do programa.