Ganhos:
- Capacidade de compreender que a inteligência artificial amplia o escopo do auditor, mas não o substitui, e é útil na varredura de categorias e na localização de redações.
- Ser capaz de reconhecer que a inteligência artificial não percebeu a vulnerabilidade original e o erro de lógica de negócios, e que uma declaração 'segura' fluente não é garantia
- Capacidade de classificar as constatações de acordo com o seu nível de gravidade e compreender que a aprovação final e a responsabilidade profissional cabem ao auditor competente.
A auditoria de segurança (exame sistemático de um contrato inteligente em busca de vulnerabilidades) é o trabalho de maior responsabilidade da Web3. Uma única linha perdida por um auditor pode resultar em perdas de milhões de dólares. Nesta unidade você aprenderá como usar a IA como assistente de auditoria; Aprenderemos desde a geração de pistas até a redação de um esboço de descobertas. Mas a frase mais crítica é esta: a IA não controla; É um auxiliar que aguça o olhar do auditor. A aprovação final cabe ao auditor competente que assume a responsabilidade profissional.
Por que a auditoria é crítica para a segurança
Um relatório de auditoria garante ao projeto e aos investidores que “este código foi revisto”. Se esta garantia for falsa, as consequências são desastrosas: protocolo explorado, perda de financiamento, projecto falido. Portanto, o uso da IA na inspeção é a parte mais cuidadosa deste módulo. A IA expande o escopo do auditor (lembra mais padrões, lê mais rápido), mas não substitui o auditor.
Por que não passa? Porque:
- A IA não consegue ver a vulnerabilidade única/nova que não está nos dados de treinamento.
- A IA muitas vezes não percebe a falha na lógica de negócios do protocolo – que o código é tecnicamente correto, mas economicamente explorável.
- A IA pode dar falsas garantias ao dizer “seguro” em linguagem fluente; Este é o resultado mais perigoso.
Camadas de uso de IA no controle
1. Varredura inicial e lembrete de padrão. A IA passa por padrões de vulnerabilidade conhecidos como uma lista de verificação: reentrada, controle de acesso, manipulação de oráculos, front-running. Isso garante que o auditor não perca nenhuma categoria.
2. Explicação do código. Explicar uma função complexa para a IA em linguagem simples permite ao auditor compreender rapidamente a lógica; mas a descrição é sempre comparada ao código.
3. Escrever um rascunho das conclusões. Quando o auditor encontra uma vulnerabilidade, a IA economiza tempo na redação do rascunho do relatório (descrição, impacto, solução proposta).
4. Gerando contra-hipóteses. Pergunte à IA "como esta função pode ser abusada?" Perguntar “nos lembra da perspectiva agressiva.
Atenção: Só porque a IA diz “Não encontrei nenhuma vulnerabilidade neste código” NÃO significa “este código é seguro”. Evidência de ausência não é ausência de evidência. O fato de a IA não conseguir encontrar algo não torna desnecessário que o auditor examine essa área.
Encontrando níveis de gravidade
As descobertas da auditoria são classificadas de acordo com seu nível de gravidade. A IA deve usar esta estrutura ao gerar rascunhos:
Nível
Significado
exemplo
crítico
Perda/bloqueio de fundos diretamente possível
Retirada de fundos com reentrada
alto
Impacto sério em certas condições
Impressão não autorizada (hortelã)
médio
Impacto limitado ou condição difícil
Pequena perda com desvio do Oracle
baixo
Risco menor, violação de boas práticas
Transmissão de evento ausente
Informação
Não segurança, legibilidade
Falta de NatSpec
Alerta fraco / Alerta forte
Alerta fraco:
Este contrato é seguro?
Esta questão força a IA a fazer um julgamento absoluto e injustificado como “sim/não” — exatamente o que não queremos.
Alerta poderoso:
Sua função: assistente do auditor sênior de contrato inteligente. Analise o contrato a seguir para segurança. Percorra as seguintes categorias, uma por uma: reentrada, controle de acesso, operações inteiras, validação de entrada, dados oracle/externos, front-running, limite de gás. Para cada ACHADO: (1) linha de código relevante, (2) risco de causa, (3) gravidade estimada (Crítica/Alta/Média/Baixa), (4) proposta de solução. Estas são HIPÓTESES A SEREM CONFIRMADAS; Não dê um veredicto "seguro". Marque as áreas que você não tem certeza de dizer claramente “deixe o auditor confirmar”.
Quatro modelos copiáveis
1) Navegação baseada em categoria:
Digitalize este contrato para as seguintes categorias: reentrada, controle de acesso, estouro de número inteiro, validação de entrada, dependência de oráculo, front-running, DoS/gas. Para cada categoria, diga "não há/há risco/não tenho certeza" e conecte sua justificativa à linha do código. Não faça um julgamento final.
2) Contra-hipótese da perspectiva do atacante:
Pense como um invasor: quais são as formas de abusar dessa função? Escreva cada cenário passo a passo e indique quais condições são necessárias. Estes cenários são as hipóteses a serem testadas; NÃO gere código de exploração real, apenas descreva o risco.
3) Projeto de relatório de conclusões:
Relate as seguintes descobertas verificadas em linguagem formal de auditoria: título, gravidade, descrição, impacto, código afetado, etapas para reprodução, solução proposta. Use linguagem comedida e técnica; exagero. Suponha que a constatação seja confirmada pelo auditor, não crie uma nova constatação.
4) Corrija a verificação:
Abaixo está uma vulnerabilidade e a correção aplicada pelo desenvolvedor. Examine se a correção realmente fecha a vulnerabilidade; marque se ele cria um novo efeito colateral ou vulnerabilidade. Não diga “fechado” com certeza; Termine com “deve ser confirmado por teste”.
Três mini cases (em números)
Caso 1 – A IA impediu o salto de categoria. Um auditor estava prestes a se concentrar em um contrato de 400 linhas e pular a categoria de oráculo. A varredura de categoria da AI alertou que “os dados de preços vêm de uma única fonte, abertos à manipulação”. O auditor examinou-o e concluiu que se tratava de facto de um risco médio. Lição: A IA mantém a disciplina de cobertura.
Caso 2 — Falsa garantia “segura”. Outra equipe perguntou à IA “isso é seguro?” ele perguntou; “Não parece haver um problema significativo”, disse AI. A inspeção da tripulação foi leve. Depois, o auditor independente encontrou uma falha na lógica empresarial: um cálculo que era tecnicamente correcto, mas cujos incentivos eram exploráveis. Lição: IA não percebe erro de lógica de negócios; Não se pode confiar nele para dizer "seguro".
Caso 3 — A elaboração do relatório economizou 3 horas. O auditor passava metade do dia relatando manualmente 8 descobertas. Depois que entreguei as descobertas verificadas à IA e imprimi o rascunho oficial, o tempo caiu cerca de 3 horas; O auditor dedicou tempo ao aprofundamento. Lição: A IA é segura e eficiente na elaboração de relatórios porque as descobertas já foram verificadas humanamente.
Vulnerabilidade da lógica de negócios: o ponto cego da IA
As vulnerabilidades mais caras muitas vezes não vêm de um erro técnico no código, mas da exploração da lógica de negócios: arredondamento da exploração de uma conta de recompensa, sequestro de voto por empréstimo instantâneo, manipulação instantânea de um preço. São casos em que o código funciona “corretamente”, mas o protocolo pode ser enganado economicamente. É provável que a IA não perceba esses erros, especialmente os específicos do protocolo. Portanto, a revisão da lógica de negócios é a área do auditor com maior intensidade humana e a menos dependente da IA.
Dica: pergunte à IA “como os incentivos econômicos deste protocolo podem ser explorados?” e use os cenários que surgirem como ponto de partida — mas lembre-se que você e sua equipe devem fazer a análise real.
Erros comuns
- Pergunte à IA "é seguro?" Pedindo e confiando no seu sim. Não é necessário julgamento absoluto.
- Interromper a revisão quando a IA disser “Não consegui encontrar”. Ausência não é evidência.
- Delegar a revisão da lógica de negócios à IA. É o seu maior ponto cego.
- Não utilizar ferramentas independentes (Slither etc.). A IA por si só não é suficiente.
- Colocar no relatório a constatação feita pela IA sem verificá-la. Risco de alucinações.
- Tentando atribuir a responsabilidade de controle à IA. A responsabilidade é do especialista.
Em resumo
- A auditoria é crítica para a segurança; A IA amplia o escopo do auditor, mas não o substitui.
- A IA não percebe a vulnerabilidade original e o bug da lógica de negócios; Dizer “seguro” não é garantia.
- Os achados são classificados de acordo com o nível de gravidade; A IA é útil na geração de rascunhos.
- A contra-hipótese e a triagem de categorias preservam a disciplina da inclusão.
- A aprovação final e a responsabilidade profissional cabem sempre ao auditor competente.
Tarefa de aplicativo
Encontre um exemplo de contrato que contenha uma vulnerabilidade conhecida (para fins educacionais, exemplos de “contratos vulneráveis” estão disponíveis em código aberto). Aplique o prompt "verificação baseada em categoria" à IA. Observe se a IA: (1) encontrou a vulnerabilidade real, (2) produziu descobertas fabricadas/falsas, (3) fez julgamentos absolutos como “seguro”. Em seguida, compare-o com uma ferramenta de análise estática.
lista de verificação
- [] Pergunte à IA "é seguro?" Em vez disso, fiz uma verificação baseada em categorias.
- [ ] Tratei cada descoberta como uma hipótese.
- [ ] Eu mesmo/equipe fiz a revisão da lógica de negócios.
- [] Fiz a validação cruzada com uma ferramenta de análise estática independente.
- [] Confirmei que a IA não fabrica descobertas.
- [ ] Classifiquei os achados de acordo com o nível de gravidade.
- [ ] Aceitei que a aprovação final cabe ao auditor competente.