Teste de Aceitação de Revisão de Segurança por IA: o que Aave V3 e V4 ensinam sobre triagem de scanners de contratos inteligentes

Comece pela restrição pouco glamorosa. Um scanner de segurança por IA pode produzir uma lista confiante de alertas em minutos. Um líder de segurança ainda precisa decidir quais alertas são reais, quais são duplicados, quais podem ser reproduzidos e quais merecem tempo dos revisores nesta semana.

É por isso que a revisão assistida por IA relatada pela Aave para Aave V3 e V4 é mais útil como teste de fluxo de trabalho do que como manchete de vitória. Aave Labs relatou 71 achados totais em três ferramentas de segurança por IA anonimizadas. A revisão manual aceitou 20. O artigo da Aave diz que os achados aceitos eram Baixos ou Informativos, enquanto vários alertas que chegaram como Críticos ou Altos foram tratados depois como falsos positivos após validação humana.

Esses números são interessantes. Eles também são fáceis de usar mal. São resultados relatados pelo projeto a partir de um escopo e método definidos. Eles não provam que um protocolo, repositório ou release é seguro. Eles mostram algo mais estreito e operacional: a saída do scanner precisa de um teste de aceitação antes de poder moldar encaminhamentos de auditoria, políticas de CI ou decisões de release em produção.

A mesma ideia se aplica fora de contratos inteligentes. Revisões de segurança de aplicações, verificações de API, varreduras de políticas de infraestrutura e revisão de código habilitada por IA enfrentam o mesmo problema. Uma ferramenta que soa certa ainda pode estar errada sobre alcançabilidade, pressupostos de função, impacto ou causa raiz duplicada. A Optijara usou o mesmo padrão de porta de aceitação para qualificação local de VLM, reprodutibilidade do algoritmo do X e infraestrutura de IA sensível a latência. Scanners de segurança devem enfrentar a mesma disciplina.

Minha visão é direta: um scanner ruidoso não é um controle de segurança. É uma fonte de pistas. Ele se torna um controle somente depois que a equipe consegue reproduzir suas entradas, normalizar seus achados, calibrar severidade e registrar decisões humanas.

Por que a revisão assistida por IA da Aave é um teste de reprodutibilidade, não uma celebração de vitória

A Aave relatou que três ferramentas de segurança por IA foram executadas contra repositórios de produção da Aave V3 e da Aave V4. As varreduras cobriram as árvores src completas em commits fixados. Onde as ferramentas ofereciam suporte, elas receberam contexto semelhante ao que auditores humanos receberiam, incluindo modelo de ameaças e contexto de auditoria.

A Aave também descreveu testes de mutação em quatro contratos da V4, Hub, Spoke, TreasurySpoke e AaveOracle. O teste usou 304 mutações deliberadas. Testes existentes eliminaram 271, enquanto 33 foram inconclusivos porque as suítes de teste atingiram timeout.

A manchete foi 71 achados apresentados e 20 aceitos após revisão manual. A melhor lição está na filtragem. A Aave diz que os achados foram classificados manualmente como válidos, falsos positivos, duplicados ou por design. É aí que vive a operação de revisão.

Um scanner que emite 71 alertas não é automaticamente mais forte do que um que emite menos. Volume pode significar cobertura. Também pode significar causas raiz repetidas, contexto fraco, pressupostos desatualizados ou explicações geradas em torno de caminhos de código que não importam. A pergunta para um gerente de segurança é mais precisa: depois de normalização, deduplicação, revisão de severidade e adjudicação humana, o que permanece?

A ausência de achados Críticos ou Altos confirmados neste escopo relatado não deve ser lida como prova de segurança. Ela significa que esses achados não foram confirmados sob o estado de código, comportamento das ferramentas, método de revisão e processo de classificação humana relatados. Isso ainda é evidência útil. Não substitui modelagem de ameaças, auditorias independentes, verificação formal, concursos, monitoramento, planejamento de resposta a incidentes ou controles de release.

A linha de base de evidência: fixação de fonte, commit, ferramenta e método

A primeira porta AISRAT é a fidelidade do artefato. Antes de qualquer pessoa debater severidade, a equipe precisa de um pacote de evidências que fixe o alvo exato da revisão. No mínimo, registre a URL do repositório de origem, hash do commit, lockfiles de dependências, versões do compilador, contêiner de build, configuração do scanner, timeouts, permissões, relatórios gerados, caminhos excluídos e notas dos revisores.

O artigo da Aave diz que as varreduras foram executadas contra commits fixados de repositórios de produção e cobriram árvores de código-fonte. Repositórios públicos do Aave V3 Origin e do Aave V4 mostram código relevante, auditorias, relatórios, testes, scripts e diretórios de documentação. Isso dá contexto útil aos leitores, mas um teste de aceitação interno precisa de mais do que contexto.

A equipe deve conseguir reconstruir o alvo a partir de um ambiente limpo e reproduzir a entrada do scanner. Se o artefato escaneado não puder ser reconstruído, a revisão de severidade já está em terreno frágil. Escopo de repositório não é a mesma coisa que escopo de código revisado. Um repositório pode conter src, testes, scripts, docs, arquivos gerados, módulos obsoletos, adaptadores e pacotes periféricos. Cada um pode afetar o volume de alertas e o trabalho dos revisores.

Scanners assistidos por IA também podem alterar a saída quando um modelo, prompt, conjunto de regras, fonte de recuperação, versão de detector ou timeout muda. Fornecedores nem sempre expõem todos os detalhes internos. Registre o que você consegue ver: versão do produto, timestamp do relatório, arquivo de configuração, template de prompt se usado, snapshot da documentação, linha de comando, parâmetros de API e variáveis de ambiente que afetam a saída.

O padrão não é reprodutibilidade acadêmica. O padrão é reprodutibilidade operacional boa o suficiente para decidir se o scanner pertence a uma rota que afeta filas de revisores, portas de CI, pacotes de auditoria ou decisões de release.

O framework AISRAT

AISRAT significa Optijara AI Security Review Acceptance Test. É um framework de decisão em seis camadas para decidir onde um scanner de IA pertence em uma rota de revisão de contratos inteligentes ou de segurança de aplicações.

A fidelidade do artefato verifica se o scanner revisou o código que importa para a equipe. Campos obrigatórios incluem repositório, commit, comando de build, compilador, locks de dependências, imagem de contêiner, caminho de origem, artefatos gerados, arquivos excluídos, versão da ferramenta, versão do modelo ou conjunto de regras quando disponível e permissões. Para contratos inteligentes, adicione versão do compilador, pressupostos de chain, configuração de implantação, dependências simuladas e testes necessários para reproduzir comportamento.

A normalização de issues torna a saída do scanner comparável antes que revisores gastem tempo com ela. Normalize cada alerta em arquivo, função, caminho de código, classe de vulnerabilidade, precondições, alegação de explorabilidade, evidência, confiança, grupo duplicado, severidade proposta, status de remediação e notas dos revisores. Narrativa longa não merece peso extra só porque parece autoritativa.

Severidade é uma alegação. Não é evidência. O AISRAT exige um argumento de explorabilidade ou impacto que se ajuste ao modelo de confiança do sistema. No artigo da Aave, a validação humana rebaixou ou rejeitou alertas que chegaram com rótulos Crítico ou Alto. A ferramenta propõe severidade. O revisor a calibra contra estado alcançável, pressupostos de função, impacto, caminho de código e modo de falha.

A adjudicação por revisores precisa de estrutura. Onde for prático, cegue os revisores quanto à identidade da ferramenta durante a primeira passagem. Registre decisões aceitas, rejeitadas, duplicadas, por design, sem suporte e de caminho de código alucinado. Inclua amostragem de falsos positivos e amostragem de falsos negativos contra vulnerabilidades conhecidas, achados históricos de auditoria, testes de mutação ou suítes com bugs semeados.

A economia de acionabilidade decide se a adoção vale o custo. Acompanhe tempo até a primeira triagem, tempo até a adjudicação, minutos de revisor por achado aceito, carga de duplicados, achados reabertos e custo por achado acionável aceito. Depois defina o que acontece após a aceitação: limites de CI, substituição por decisão humana, pacotes de encaminhamento para auditoria, fluxo de divulgação, controle de acesso, telemetria, canários, critérios de rollback e testes de regressão.

{
  "framework": "AISRAT",
  "minimumEvidence": ["repo", "commit", "build", "toolConfig", "normalizedFinding", "reviewerDecision"],
  "routeOptions": ["research", "triageAssistant", "ciSignal", "auditInput"],
  "acceptanceQuestion": "Does the scanner produce reproducible, evidence-backed, non-duplicate findings at an acceptable reviewer cost for this route?"
}

Matriz de decisão de rota

Um scanner com ideias úteis, mas reprodutibilidade fraca, ainda pode pertencer à rota de pesquisa. Uma porta de CI precisa de um padrão mais alto porque pode desacelerar a entrega ou criar falsa confiança. Entrada para auditoria formal precisa do pacote de evidências mais limpo porque auditores devem conseguir inspecionar decisões aceitas e rejeitadas, não apenas a lista final de defeitos.

Checklist de implementação do AISRAT

Para contratos inteligentes, adicione compilação de contratos, pressupostos de implantação, funções de governança, dependências de oráculo, funções privilegiadas, pressupostos de mensagens cross-chain e testes de invariantes ou fuzz. Para segurança de aplicações, adicione versões de serviço, esquemas de API, fluxos de identidade, classificação de dados, paridade de ambiente e estado do grafo de dependências.

Erros comuns

Contagem de alertas é o número mais fácil de vender e o mais fraco para operar. Ela recompensa ferramentas verbosas e penaliza ferramentas que suprimem saída de baixa confiança. A melhor medida são achados acionáveis aceitos após normalização, deduplicação e adjudicação por revisores.

Um rótulo Crítico sem um caminho executável ou revisável não é uma vulnerabilidade Crítica. O AISRAT pede aos revisores que separem classe de vulnerabilidade de evidência de explorabilidade, estado alcançável, pressupostos de função e impacto. Isso importa em sistemas com funções de governança, timelocks, pressupostos de oráculo e comportamento deliberado de revert.

Duplicados consomem tempo dos revisores. Arquivos alucinados, caminhos inalcançáveis, recursos de framework sem suporte, dependências desatualizadas e alvos que não compilam podem fazer um scanner parecer produtivo enquanto adicionam pouco valor de segurança. Acompanhe esses casos como categorias próprias. Alucinações rejeitadas devem virar exemplos de regressão para que a mesma ferramenta não as devolva como issues novas.

Falsos positivos são fáceis de ver porque revisores ficam olhando para eles. Falsos negativos exigem testes deliberados. Use vulnerabilidades conhecidas, issues históricas de auditoria, testes de mutação, suítes com bugs semeados e linhas de base convencionais de análise estática. Um scanner com menos falsos positivos ainda pode ser um sinal de CI ruim se perder issues conhecidas.

Plano de medição

Compare a rota assistida por IA com uma linha de base usando o mesmo artefato fixado e o mesmo modelo de ameaças. A linha de base pode ser revisão apenas humana, análise estática convencional ou a suíte de scanners existente da equipe. Metas universais de precisão geralmente são preguiçosas. Linguagem, framework, maturidade do código, qualidade do contexto e modelo de ameaças mudam o nível de ruído aceitável.

Comece com um piloto com escopo: um repositório, um commit, um modelo de ameaças, uma rota. Decida se o scanner merece ser auxílio de pesquisa, assistente de triagem, sinal de CI ou entrada de auditoria. Expanda somente depois que o pacote de evidências estiver bom o suficiente para alguém fora da equipe imediata inspecionar.

A revisão da Aave é útil porque mostra a lacuna entre severidade do scanner e evidência confirmada por humanos. O AISRAT transforma essa lacuna em um sistema de gestão. Ele protege revisores contra ruído, dá feedback concreto a fornecedores e ajuda equipes a adotar revisão de segurança assistida por IA sem fingir que a ferramenta virou o auditor. Se sua equipe está desenhando uma rota de revisão assistida por IA, a Optijara pode ajudar a definir portas de aceitação, plano de medição e controles de governança antes que o scanner comece a influenciar decisões de produção.