Ganhos:
- Capacidade de reconhecer padrões de vulnerabilidade comuns, como reentrada, controle de acesso, manipulação de oráculos e front-running e digitalizá-los com uma ferramenta de análise estática + inteligência artificial + humana
- Capacidade de distinguir entre os pontos fortes da IA ao explicar o resultado da ferramenta e priorizar falsos positivos e pontos fracos no MEV e na lógica de negócios
- Entenda que uma 'varredura limpa' não é um certificado de segurança, que a varredura é apenas uma camada de controle
Vimos a disciplina holística da auditoria na unidade anterior. Nesta unidade, nos concentramos em um tópico mais técnico: verificação de vulnerabilidades — a busca sistemática por padrões de vulnerabilidade conhecidos no código. Aqui usaremos IA, juntamente com ferramentas de análise estática, como um assistente que verifica e descreve padrões de vulnerabilidade conhecidos. O objetivo: conhecer em profundidade as vulnerabilidades mais comuns e distinguir onde a IA é confiável e onde é inadequada para verificá-las.
Verificação estática e dinâmica
A digitalização é de dois tipos. Análise estática – examinando o código sem executá-lo: Ferramentas como Slither e Mythril verificam o código do contrato e sinalizam padrões conhecidos. Análise dinâmica/simbólica (executar o código com entradas diferentes ou explorá-lo matematicamente): fuzzing (bombardear com entradas aleatórias) e execução simbólica (explorar todos os caminhos possíveis) se enquadram neste grupo.
A IA não substitui estas ferramentas, mas complementa-as: quando o veículo emite um aviso, a IA explica o aviso em linguagem simples; A IA pode lembrar quando a ferramenta perde um padrão; Mas a IA por si só não pode garantir o quanto ela verifica. O fluxo de trabalho certo: ferramenta + IA + humano.
Dica: forneça à IA o resultado de uma ferramenta de análise estática (por exemplo, relatório Slither) e pergunte “explique cada alerta em linguagem simples, quais são riscos reais e quais podem ser falsos positivos?” perguntar. A IA é inestimável para tornar o resultado bruto da ferramenta compreensível e priorizável para os humanos.
Padrões de vulnerabilidade mais comuns
1. Reentrada. Se uma função chamar um contrato externo sem atualizar seu estado, o contrato chamado poderá voltar, acionar a mesma função novamente e retirar o fundo várias vezes. Solução: ordem de verificações-efeitos-interações e guarda de reentrada.
2. Falta de controle de acesso. Uma função crítica (retirada, retirada, atualização) é acidentalmente tornada pública. É um dos erros mais comuns e caros.
3. Manipulação do Oráculo. A dependência cega do contrato em uma fonte externa de preços (oráculo). O invasor manipula o preço instantaneamente e engana o protocolo. Solução: preço médio ponderado no tempo (TWAP), multifonte.
4. Estouro/underfall de inteiros. Quando um número excede o valor máximo permitido e retorna ao início. O Modern Solidity captura a maior parte automaticamente, mas o risco permanece no código de baixo nível (assembly).
5. Frente. As transações aparecem no pool público (mempool) antes de serem confirmadas; O invasor pode ver sua transação e inserir sua própria transação na frente dela. MEV (Maximal Extractable Value — o valor extraído da sequência de transação) é o nome geral deste assunto.
6. Negação de Serviço (DoS). Um loop torna-se muito caro e torna a função inutilizável, ou uma dependência de um endereço fica bloqueada.
7. Riscos de atualização. Colisão de armazenamento e abuso de autoridade em contratos atualizáveis.
vulnerabilidade
Confiança na varredura de IA
Por que
reentrada
alto
Padrão claro e bem conhecido
controle de acesso
alto
O molde pode ser digitalizado
Operações inteiras
alto
controle padrão
Manipulação do oráculo
médio
Requer contexto
Front-running/MEV
Médio-Baixo
específico do protocolo
erro de lógica de negócios
baixo
Autêntico, contextual
Alerta fraco / Alerta forte
Alerta fraco:
Existe uma lacuna neste código?
Alerta poderoso:
Sua função: assistente de triagem de segurança. Verifique o contrato abaixo em busca dos seguintes padrões conhecidos e "em risco/não/inseguro" para cada um: reentrada, controle de acesso, operações inteiras, dependência de oracle, front-running, DoS, segurança de atualização. Vincule cada determinação à linha relevante e explique por que existe um risco. São hipóteses que SERÃO VERIFICADAS com ferramenta de análise estática e auditor. Observe que pode haver falsos positivos.
Quatro modelos copiáveis
1) Descrição da saída da ferramenta:
Abaixo está o relatório de uma ferramenta de análise estática (Slither). Explique cada alerta em linguagem simples: o que significa, é um risco real ou um possível falso positivo, qual deve ser a sua prioridade? Não tome uma decisão firme; Priorize a confirmação do auditor.
2) Triagem focada na reentrada:
Encontre todas as funções que fazem chamadas externas neste contrato. Examine se a ordem de verificações-efeitos-interações é seguida para cada um deles e se há guarda de reentrada. Mostre os arriscados com uma linha. Marque se não tiver certeza; Gerando código de exploração.
3) Mapa de controle de acesso:
Liste todas as funções externas/públicas neste contrato e especifique “quem pode ligar” (todos/proprietário/função) para cada uma. Realize operações críticas (retirada, impressão, atualização) e marque aquelas com controle de acesso fraco. Apresente-o com uma mesa.
4) Eliminação de falso positivo:
Considere por que esse aviso de verificação pode não ser um risco REAL (falso positivo): qual contexto ou condição de código invalidaria esse aviso? Mas não diga “não há absolutamente nenhum problema”; Liste os pontos que precisam de confirmação.
Três mini cases (em números)
Caso 1 — Veículo + IA dobraram a eficiência. Uma equipe executou o Slither em um projeto de 12 contratos e recebeu 140 avisos. Depois que a IA explicou e priorizou os alertas, descobriu-se que 95 dos 140 alertas eram falsos positivos; A equipe se concentrou em 45 candidatos reais. O tempo de triagem diminuiu de 2 dias para 5 horas. Lição: A IA é poderosa para humanizar a produção de veículos.
Caso 2 – MEV sequestrado por IA. Em um contrato DEX (troca descentralizada), a IA encontrou os padrões padrão limpos, mas não conseguiu detectar uma vulnerabilidade inicial; porque isso era específico da ordem de operações do protocolo. Auditor humano e simulação capturados. Lição: Os riscos específicos do protocolo, como MEV/front-running, são a área fraca da IA.
Caso 3 — Evitou perder tempo com um falso positivo. A equipe foi poupada de uma reescrita desnecessária quando a IA explicou que um aviso de reentrada era na verdade um falso positivo (a função já estava protegida). Mas a equipe ainda confirmou isso com um único teste. Lição: A IA prioriza; A confirmação novamente vem com testes.
Limites de digitalização
A varredura encontra padrões conhecidos. Nem a ferramenta nem a IA têm garantia de detectar uma vulnerabilidade nova, única ou específica do protocolo. Portanto, a triagem faz parte da auditoria; não ele mesmo. A ideia de que “a verificação está limpa, então significa que é segura” é um dos equívocos mais perigosos neste campo. A dragagem coleta os frutos mais fáceis de alcançar; Para riscos profundos e únicos, a experiência humana, os testes, a difusão e a auditoria formal são essenciais.
Cuidado: um relatório “limpo” de uma ferramenta de verificação ou IA não é um certificado de segurança. Apresentá-lo dessa forma – especialmente aos investidores – é enganoso e antiético.
Erros comuns
- Substituindo triagem por inspeção. A digitalização é uma camada, não o todo.
- Usando IA sem ferramentas. Análise estática + IA + trabalho humano juntos.
- Eliminando falsos positivos sem confirmação. Cada tela é testada/verificada por humanos.
- Ignorando os riscos específicos do protocolo (MEV) confiando na IA. A área fraca da IA.
- Pensando em "varredura limpa" = "seguro". Não consegue encontrar o desconhecido.
- Gerando código de exploração. Apenas a descrição defensiva do risco é legítima.
Em resumo
- A verificação de vulnerabilidades procura padrões de vulnerabilidade conhecidos com veículo + IA + humano.
- A IA é poderosa para explicar e priorizar resultados de ferramentas de análise estática.
- Confiável em padrões claros como reentrada e controle de acesso; Fraco em MEV e lógica de negócios.
- Até mesmo a eliminação de falsos positivos requer confirmação.
- Uma “varredura limpa” não é um certificado de segurança; Não substitui a supervisão.
Tarefa de aplicativo
Execute uma ferramenta de análise estática em um contrato de amostra (se possível) ou encontre um relatório Slither pronto. Aplique o prompt "descrição da saída da ferramenta" ao AI. Avalie se a IA: (1) explica corretamente os avisos, (2) faz sentido na distinção entre falsos positivos e (3) ignora um risco específico do protocolo. Preencha as colunas “veículo encontrado / IA explicada / confirmação humana” em uma tabela.
lista de verificação
- [] Posicionei a hachura como uma camada do controle.
- [] Usei ferramenta de análise estática + IA + humano juntos.
- [] Pesquisei categoria por categoria por padrões conhecidos.
- [] Eliminei falsos positivos com confirmação.
- [] Confiei em humanos em áreas fracas, como MEV/lógica de negócios.
- [ ] Eu não ofereci uma "varredura limpa" como garantia.
- [ ] Trabalhei apenas para fins de defesa; Eu não criei explorações.