Ir para o conteúdo
CodeAuditAgent
Todos os artigos

Dois motores, uma auditoria

Por que um segundo modelo de IA lendo o mesmo código muda o que a auditoria encontra e como dois relatórios viram um sem dobrar o ruído.

· 5 min de leitura · Lina Source LLC

Peça a dois revisores experientes que leiam a mesma pull request e você recebe duas listas diferentes. Um percebe que o identificador na URL nunca é conferido contra a sessão; o outro nota que o laço de retentativa deixa uma conexão de banco aberta a cada falha. Nenhum está errado e nenhum está completo. Modelos de linguagem se comportam do mesmo jeito, pelo mesmo motivo: o que um revisor percebe depende do que ele já viu.

Concordância é sinal

Um modelo sozinho informa a própria confiança. Esse número vale algo, mas é autodeclarado: o modelo corrige a própria prova. Quando dois modelos treinados por laboratórios diferentes, com dados diferentes e fraquezas diferentes, chegam de forma independente à mesma falha no mesmo arquivo, essa concordância é evidência vinda de fora do modelo. É o mais perto de uma segunda opinião que uma revisão automatizada consegue chegar.

O inverso importa tanto quanto. Um achado relatado por apenas um motor não é falso por isso, e descartá-lo seria jogar fora justamente os bugs que um revisor sozinho encontra bem. Ele deve ser relatado e atribuído, para que você mesmo avalie.

Onde um motor fica calado

Na prática os dois motores divergem mais nas classes de bug que exigem raciocínio em vez de reconhecimento de padrões:

  • Falhas de lógica: um desconto aplicado duas vezes, uma máquina de estados que aceita reembolso depois de um reembolso, uma checagem de propriedade feita no objeto errado.
  • Autorização específica do framework: middleware que protege um grupo de rotas, mas não o handler de API montado ao lado.
  • Vazamentos de recurso e memória: listeners, timers e conexões abertos por requisição e liberados apenas no caminho feliz.
  • Prompt injection escondida em comentários ou fixtures, que se lê como texto inofensivo se você não estiver procurando.

Como dois relatórios viram um

A junção é onde o segundo motor se paga ou dobra o seu ruído. As regras que adotamos:

  • Os achados são casados pelo que identifica o bug, não pela redação: sua classe CWE e o arquivo onde ele está.
  • Uma correspondência é relatada uma vez, com a mais rígida das duas severidades, porque a leitura segura é aquela sobre a qual se age.
  • Fica a redação com que um desenvolvedor consegue trabalhar: a evidência mais longa, o patch concreto, os passos ordenados.
  • Um achado corroborado sobe para confiança alta e recebe o rótulo dos dois motores.
  • Um achado visto por apenas um motor é mantido, marcado com o motor que o encontrou.

Os dois motores leem a mesma fonte ao mesmo tempo, então a auditoria não demora o dobro; ela custa o dobro para rodar, e é por isso que pertence ao plano Pro. Se o segundo motor estiver indisponível ou devolver algo inaproveitável, a auditoria termina com o primeiro em vez de falhar.

Nada disso torna um relatório verdadeiro. Dois motores podem concordar e ambos errarem; a evidência citada sob cada achado existe justamente para você conferir em vez de confiar. O que a corroboração dá é uma ordem: quando chegam cem achados e você tem uma tarde, comece pelos que dois revisores independentes viram.