Como NÃO Falhar na Auditoria de Smart Contracts: Um Guia Completo
Evite os erros mais comuns em auditorias de smart contracts. Este guia detalha as quatro fases essenciais do processo: inicial, preparatória, principal e final, com dicas práticas para garantir o sucesso.
MundiX News·13 de maio de 2026·15 min de leitura·👁 5 views
Olá, comunidade!
Sou Dmitry, um ex-desenvolvedor de smart contracts (desde 2017) e, desde 2022, atuo como auditor de smart contracts. Este artigo é para todos que se interessam por segurança da informação e, especificamente, pela auditoria de smart contracts, ou pelo processo de auditoria em geral.
Ao final de uma auditoria, duas perguntas sérias podem surgir: "Por que não tivemos tempo para nada?" e "Por que não encontramos nada?". A situação mais assustadora é quando ambas as perguntas surgem simultaneamente. Podemos resumir isso em uma única palavra: "Falha".
Como tentar prevenir o surgimento dessas perguntas? Para responder a isso, tentarei primeiro descrever o processo de auditoria. Por que descrever a auditoria como um processo? Porque a "falha" muitas vezes não ocorre na busca por vulnerabilidades ou no uso de ferramentas, mas sim na parte organizacional.
Naturalmente, tudo depende dos objetivos e do escopo de uma auditoria específica. Se um processo típico de busca por vulnerabilidades é descrito em algum lugar, ele geralmente consiste nas seguintes etapas:
Preparação: Coleta de informações, análise de requisitos, etc.
Análise Estática: Análise do código sem executá-lo.
Análise Dinâmica: Execução do código para observar seu comportamento.
Testes de Penetração: Tentativas de explorar vulnerabilidades encontradas.
Relatório: Documentação das descobertas e recomendações.
Durante a auditoria, a busca por vulnerabilidades é, de fato, uma etapa importante e principal. No entanto, não há menção à preparação! Neste artigo, tentarei descrever um processo típico de auditoria, usando sistemas de smart contracts como exemplo, desde o início até o relatório final, que é dividido em quatro etapas:
Inicial
Preparatória
Principal
Final
Vamos apresentá-las em uma tabela e adicionar o que já sabemos.
Conscientemente, omitirei os aspectos relacionados à avaliação do escopo da auditoria (seja um repositório ou smart contracts já implantados na rede), elaboração de propostas comerciais, definição de prazos e assinatura de contratos (ou seja, a etapa de negociação). Começarei imediatamente a partir do momento em que o cliente e o prestador de serviços (ou seja, nós) concordarem em realizar a auditoria.
Etapa Inicial
Antes de iniciar a análise do sistema de smart contracts, por nosso lado (o prestador de serviços), um responsável pela auditoria deve ser designado. Esta é a primeira coisa a ser feita no início. O responsável pode ser um líder de equipe, um auditor experiente ou um gerente de projeto, o importante é que ele compreenda o processo.
Também, antes do início da auditoria, é desejável definir os canais de comunicação com o cliente (seu representante ou desenvolvedores), seja um chat em um aplicativo de mensagens ou, por exemplo, um escritório específico nas instalações do cliente, onde serão realizadas reuniões de trabalho.
Recomendo discutir e registrar em algum lugar (chat ou papel) as informações sobre os objetivos, escopo, critérios e métodos da auditoria, bem como a composição da equipe de auditoria.
Uma questão importante separada é o acesso à infraestrutura onde os smart contracts são executados. É necessário esclarecer as especificidades do ambiente de execução, seja um blockchain privado ou público, software de nós ou smart contracts pré-compilados que podem ser específicos para um determinado blockchain. Tudo precisa ser esclarecido! E é melhor fazer isso "logo de cara".
Sobre o que mais às vezes se esquece durante a auditoria? É a sua influência direta nos processos do cliente.
Exemplo: Durante suas atividades, os auditores fazem perguntas aos desenvolvedores, e estes estão com o "produção fora do ar" e buscam freneticamente a causa. Portanto, idealmente, deve haver um cronograma flexível para a auditoria, com "janelas" de comunicação previamente alocadas com os desenvolvedores ou o representante do cliente.
Sem feedback dos desenvolvedores, a qualidade da auditoria pode ser prejudicada (e queremos que a auditoria corra bem!).
Auditores qualificados também sabem da existência de um Acordo de Não Divulgação (NDA). No mundo ideal, antes da auditoria, todos os parâmetros de confidencialidade são acordados entre o cliente e o prestador de serviços, e o procedimento para divulgação das vulnerabilidades encontradas é obrigatoriamente aprovado.
E a cereja do bolo da etapa inicial é o esclarecimento por parte dos auditores sobre qual parte do sistema deve ser enfatizada. Se o sistema consiste em dois módulos, e um deles tem documentação completa, coberto por testes, e o segundo "foi finalizado ontem", é lógico focar no módulo "novo", especialmente onde ele interage com o "antigo".
E agora, sobre o que alguns, por circunstâncias, temem falar. O responsável pela auditoria, já na etapa inicial, deve determinar se a auditoria é possível. É possível atingir os objetivos, mesmo que teoricamente? Se a auditoria for inviável (por exemplo, o volume aumentou drasticamente), ou se houver obstáculos significativos que possam afetar a qualidade da auditoria, é melhor comunicar tudo isso com antecedência, e para algumas organizações isso é feito exclusivamente por escrito. Isso pode levar a conflitos, mas estamos falando sobre como NÃO falhar na auditoria.
Da prática pessoal:
Você e sua equipe chegam às instalações do cliente, onde há controle de acesso, e descobrem que a lista de pessoas autorizadas está desatualizada! E dois dos cinco auditores não conseguem passar pelo posto de controle... Se você veio por duas semanas e resolveu essa questão em meio dia, tudo bem, mas e se for por dois dias? Tais questões devem ser sempre resolvidas com antecedência. E é ainda melhor evitar tais deslizes.
Para resumir o acima exposto. Ao final, a etapa inicial se parece com isto:
Designado um responsável pela auditoria;
Definido o procedimento de interação com os desenvolvedores e/ou cliente;
Esclarecidos e confirmados os objetivos e escopo da auditoria;
Acordados os parâmetros de confidencialidade;
Garantido o acesso à infraestrutura (se necessário) e resolvidas as questões organizacionais.
Voltando à nossa tabela, adicionaremos novos dados.
Etapa Preparatória
Se os detalhes da etapa inicial foram acertados e não há obstáculos visíveis, parabéns! Podemos começar. Começar a auditoria em si? Não! Começar a preparar para a auditoria, ou seja, agora algumas palavras sobre a etapa preparatória da auditoria.
Em primeiro lugar, é necessário verificar se, além do código, existe documentação e, se a resposta for "Sim", verificar em que formato. A existência de documentação é uma faca de dois gumes: você pode acreditar que tudo lá é verdade, e isso será um erro fatal. Ter uma ideia do conteúdo da documentação pode ser útil para esclarecer o funcionamento de smart contracts específicos, suas funções e parâmetros. O volume da documentação também é muito importante; se a auditoria dura uma semana, e a documentação leva um mês para ser lida... esperar que você consiga mergulhar nela é um absurdo. Atenção especial deve ser dada a esquemas e diagramas, se houver.
Se a base de código com smart contracts já passou por auditoria, é desejável ter em mãos os relatórios das verificações anteriores. Isso pode ajudar com vetores de ataque e dar uma compreensão do que o grupo de auditoria anterior enfatizou.
Na etapa inicial, um dos focos foi o acesso à infraestrutura; nesta etapa, o foco se desloca diretamente para a estrutura dessa infraestrutura. Agora é necessário não apenas esclarecer o ambiente de execução dos smart contracts (incluindo smart contracts pré-compilados, redes de consenso, privacidade ou publicidade do blockchain, etc.), mas também avaliar os riscos e oportunidades associados a isso.
Primeiro, precisamos aprovar a composição da equipe de auditoria e sua competência geral. Em seguida, escolhemos os métodos adequados para a auditoria e estimamos como podemos aumentar sua eficácia. Por exemplo, a base de código contém várias bibliotecas matemáticas, um ótimo lugar para fuzzing, e, consequentemente, incluímos na equipe de auditoria um especialista que conhece fuzzing como a palma da sua mão.
Em seguida, vale a pena elaborar um plano de cronograma de auditoria; a detalhe do plano deve refletir a área e a complexidade da auditoria. Outra questão que o plano de cronograma resolve é a distribuição de tarefas entre os auditores. Parece que isso é claro para qualquer um, especialmente se a equipe de auditoria for pequena e composta apenas por especialistas experientes, eles podem resolver isso sozinhos. Mas em auditorias de longa duração e quando a equipe de auditores é composta por cinco ou mais especialistas, a questão da distribuição de tarefas deve receber atenção especial.
O que mais é desejável considerar no plano? Reuniões de trabalho. No mundo ideal, a comunicação com os desenvolvedores está disponível 24 horas por dia, eles são amigáveis e correm para responder às suas perguntas ao primeiro chamado. Mas na realidade, é desejável coordenar e adicionar reuniões de trabalho ao plano de cronograma. Durante a auditoria, colete perguntas dos especialistas e, quando houver um número suficiente delas, envie todo o lote aos desenvolvedores para comentários. Isso pode ser feito pessoalmente, online ou em formato híbrido. Também é importante lembrar que o cliente quer ver pelo que pagou, mesmo antes do relatório final, portanto, mais perguntas e mais reuniões de trabalho eficazes!
Se necessário, o plano de cronograma de auditoria deve ser mostrado ao cliente ou seu representante. Todas as perguntas surgidas em relação a tal plano devem ser resolvidas no início.
O que pode faltar no plano? Flexibilidade. Isso é muito importante em auditorias de longa duração. Durante a auditoria, novas circunstâncias podem surgir, que não eram conhecidas antecipadamente e podem afetar o resultado. É importante reagir a elas rapidamente.
Da prática pessoal:
Um grande protocolo, representando uma plataforma de crédito, consistindo em dezenas de smart contracts, uma pilha de parâmetros, módulos de interação com exchanges descentralizadas e pontes... Após uma semana de busca por vulnerabilidades, ficou claro que havia muitas vulnerabilidades críticas, que foram prontamente fornecidas ao cliente. Eles reagiram positivamente. E uma semana depois, a equipe de auditoria apresentou um novo conjunto de vulnerabilidades confirmadas, demonstrando falhas arquitetônicas fundamentais... O protocolo desenvolvido, devido a nuances do blockchain, era inviável. O projeto teve que ser encerrado, mas o cliente foi compreensivo e permaneceu grato, pois os riscos de perda de fundos e reputação no campo público eram maiores para ele do que uma conclusão de auditoria "negativa".
Um exemplo mais simples de imprevistos: uma vez nos colocaram em uma sala onde não havia eletricidade o dia todo devido a alguns trabalhos externos, e nem todos tinham laptops carregados... No final, tivemos que esperar algumas horas até que a eletricidade fosse ligada.
Outra questão que não abordei, mas que também deve ser refletida no plano, são os critérios de vulnerabilidade. Dependendo do cliente, das condições e dos objetivos da auditoria, os critérios podem ser diferentes. Por exemplo:
"Pessoal, procurem apenas críticas, esta é uma versão intermediária."
A fase final desta etapa é a preparação de ferramentas e software especializados. Os membros da equipe de auditoria, com base em suas tarefas, devem preparar as ferramentas necessárias (por exemplo, checklists ou uma base de vulnerabilidades conhecidas) e o software especializado em si (por exemplo, analisadores estáticos, ferramentas de verificação formal ou um LLM local de trabalho).
Por fim, falarei sobre dois pequenos casos que ocorrem na minha prática com extrema raridade, mas que valem a pena mencionar. O primeiro está relacionado à definição do idioma de trabalho para interação (por exemplo, russo ou inglês) e o idioma do relatório (eles também podem diferir). E o segundo caso diz respeito à coordenação com as atividades de outros auditores em caso de auditoria conjunta ou verificação paralela.
Resumimos o checklist para a etapa preparatória:
Verificar a existência, volume e qualidade da documentação (incluindo esquemas, diagramas e relatórios de auditoria anteriores);
Esclarecer as características, parâmetros do ambiente de execução dos smart contracts e sua estrutura;
Elaborar um plano de cronograma detalhado, aprovar a composição da equipe de auditoria e distribuir tarefas;
Definir critérios para vulnerabilidades;
Preparar ferramentas e software especializados.
Voltando ao esquema geral e atualizando-o.
Etapa Principal
Normalmente, o próprio processo de auditoria da base de código é realizado em uma sequência estritamente definida.
No entanto, essa sequência pode mudar dependendo das circunstâncias de uma auditoria específica.
Repito que, em primeiro lugar, é necessário distribuir as responsabilidades entre os membros da equipe de auditoria. Se houver um único especialista, ele, como um homem-orquestra, realiza todo o trabalho sozinho. Se houver vários auditores, há uma alta probabilidade de duplicação de trabalho: por exemplo, cada um executa o analisador estático Slither e todos recebem o mesmo relatório.
A auditoria como processo impõe certos requisitos de concentração, portanto, se houver observadores externos ou acompanhantes, é desejável reduzir sua influência na equipe de auditoria. Talvez isso soe muito trivial, mas: não atrapalhe as pessoas trabalhando! Se você está nas instalações do cliente e na sala ao lado estão quebrando paredes para instalar tomadas – parabéns! Neste caso, o resultado final será menor. O responsável pela auditoria deve garantir as condições adequadas para a realização do trabalho o máximo possível, e aqui os acompanhantes e observadores podem ser muito úteis.
As responsabilidades entre os auditores estão distribuídas, as condições estão garantidas – é hora da primeira reunião de trabalho. Ela pode ocorrer offline e online, em algum chat ou por videoconferência. É mais fácil se reunir online, mas de qualquer forma, é necessário apresentar ao cliente os membros da equipe de auditoria e explicar suas funções. Novamente, imaginemos o mundo ideal onde, além do CEO ou seu representante, estão presentes os desenvolvedores que estão prontos para responder a quaisquer perguntas... Em seguida, o plano de auditoria é apresentado, a tarefa é coordenar e registrar no plano todas as reuniões de trabalho intermediárias e, o mais importante, o procedimento para informar o cliente e os desenvolvedores sobre o andamento da auditoria e as vulnerabilidades encontradas.
A seguir, apresentarei uma tese sobre a troca de informações. Ela não é obrigatória para a equipe de auditoria (devido ao fato de que os processos, estilos e tipos de auditoria podem ser diferentes), mas é recomendado reunir-se periodicamente para trocar informações, para entender como a busca por vulnerabilidades está progredindo e, se necessário, redistribuir tarefas entre os membros da equipe de auditoria. Para o cliente, os meios de troca de informações podem variar de um chat em um aplicativo de mensagens a canais de comunicação seguros especiais; este ponto também precisa ser discutido e aprovado.
Vale a pena falar separadamente sobre vulnerabilidades significativas. Tais vulnerabilidades devem ser repassadas sem demora ao cliente e, se necessário, aos desenvolvedores. Naturalmente, exceto nos casos em que foi acordado que ninguém deveria ser incomodado: "Mostrem todos os bugs, mesmo os críticos, em três semanas".
Uma das situações mais desagradáveis que podem ocorrer em um projeto é a impossibilidade de cumprir as tarefas no prazo. Nesses casos, o líder da auditoria deve informar o cliente com antecedência para determinar o que fazer a seguir. Para não pintar um quadro sombrio, direi que isso pode ser não apenas a interrupção da auditoria, mas apenas uma mudança no plano, um aumento do prazo ou o adiamento da auditoria para outras datas.
Três Abordagens para Auditoria
Chegou a hora de falar sobre as abordagens para a busca de bugs. Destacarei três principais: métodos de "caixa branca", "caixa preta" e "caixa cinza".
Mas antes de passar para as abordagens, vamos lembrar que uma aplicação blockchain típica consiste em pelo menos quatro partes interdependentes:
Plataforma Blockchain (como ambiente de execução de smart contracts)
Pode conter vulnerabilidades de criptografia, consenso, logging, acesso ao gerenciamento de nós, gerenciamento de chaves de nós;
Smart Contracts
Podem conter vulnerabilidades de lógica de execução de processos de negócios, implementação técnica de processos de negócios;
Aplicação de Negócios
Pode conter vulnerabilidades de gerenciamento de chaves, distorção de dados antes ou depois do envio para smart contracts;
Nível Organizacional
Pode conter características que afetam o acesso dos participantes aos artefatos da aplicação blockchain e a atualização do código-fonte.
Um pouco sobre "caixa branca"
Nesta abordagem, há acesso a todas as partes do projeto, à base de código e à documentação do projeto. O objetivo do auditor é, na maioria das vezes, identificar vulnerabilidades antes do lançamento do projeto ou antes da atualização do produto com nova funcionalidade.
O procedimento para esta abordagem consiste em três etapas e se parece com isto:
Análise Preliminar: Entendimento geral da arquitetura e identificação de riscos potenciais.
Análise de Código e Testes: Busca detalhada por vulnerabilidades e desenvolvimento de provas de conceito.
Verificação Final: Revisão manual e uso de ferramentas para garantir cobertura completa.
Na primeira etapa, as seguintes ações são realizadas:
Revisão da arquitetura do projeto;
Análise da documentação do projeto;
Análise geral do código;
Engenharia reversa para analisar a arquitetura do projeto com base exclusivamente no código-fonte;
Desenvolvimento de um ponto de vista independente sobre a arquitetura do projeto;
Identificação de quaisquer deficiências lógicas no design.
O objetivo desta etapa é entender a estrutura geral do projeto e identificar riscos de segurança potenciais.
Na segunda etapa, realizamos as seguintes ações:
Análise principal do código com técnicas de hacking;
Identificação de vulnerabilidades;
Desenvolvimento de Provas de Conceito (Proof-of-Concept, PoC);
Realização de testes de fuzzing;
Uso de ferramentas de verificação formal;
Análise de casos de teste e comentários no código.
O objetivo principal desta etapa é identificar e eliminar a maioria das vulnerabilidades, incluindo aquelas exclusivas de sistemas distribuídos (aka blockchain).
Na terceira etapa, realizamos:
Verificação manual do código usando checklists internos e externos;
Uso de ferramentas de análise estática e bancos de dados de vulnerabilidades.
Aqui, o principal objetivo é garantir uma cobertura abrangente dos vetores de ataque conhecidos.
Como podemos ver, esta abordagem é adequada quando você tem tudo (código e documentação), e o mais importante, tem tempo para realizar todas as ações.
Um pouco sobre "caixa preta"
Nesta abordagem, a verificação começa com a solicitação de todos os dados disponíveis e endereços de smart contracts no blockchain (aka ledger distribuído). Não há código! Ou melhor, você só tem o bytecode implantado na rede.
O procedimento neste caso, no papel, é muito mais simples:
Descompilação do código do nó ou dos smart contracts;
Reconstrução do código-fonte a partir da forma descompilada;
Aplicação de cenários típicos de execução de nós e uso de smart contracts.
Mas pode acontecer, como diz o ditado: "no papel era liso, mas esqueceram dos barrancos". Esta abordagem é extremamente trabalhosa e requer mais tempo para a verificação. Uma verificação abrangente neste caso nem sempre é possível, portanto, recomendo limitar-se à aplicação de cenários típicos.
Um pouco sobre "caixa cinza"
A opção mais comum e prática. Nesta abordagem, o auditor tem acesso parcial às informações do projeto (por exemplo, acesso limitado ao código-fonte, documentação, configurações, ambiente de teste ou API) e tempo limitado. Esta abordagem inclui uma combinação das abordagens de "caixa preta" e "caixa branca", mas sob restrições. Naturalmente, tal abordagem tende mais para a "caixa branca", pois temos algo em mãos.
O objetivo principal nesta abordagem é identificar vulnerabilidades com conhecimento limitado da arquitetura e lógica do projeto. Encontrar ataques que se aproximem o máximo possível das condições e cenários reais. Na maioria das vezes, os vetores de ataque de um usuário privilegiado, integrador ou usuário comum são verificados.
O procedimento (talvez algo precise ser pulado devido à falta de tempo):
Análise da documentação e arquitetura fornecidas;
Análise das partes disponíveis do código-fonte;
Análise das configurações do ambiente de teste;
Estudo das limitações do armazenamento de dados e sistemas externos;
Modelagem de ataques considerando a arquitetura conhecida;
Análise da comunicação de rede e API;
Tentativas de escalonamento de privilégios usando os papéis apresentados;
Aplicação de cenários de exploração típicos e combinados.
Na vida real, o auditor mais frequentemente encontra a "caixa cinza", na vida de um hacker, a "caixa preta", e o líder da auditoria sonha com a "caixa branca".
Busca por Vulnerabilidades
Após a escolha da abordagem, pode-se prosseguir diretamente para a auditoria, especificamente no sentido de buscar vulnerabilidades. A análise da documentação pode ajudar a encontrar vetores de ataque adequados, e as discrepâncias encontradas entre a documentação e o estado atual do sistema também podem ser registradas de certa forma como vulnerabilidades, e as informações sobre elas devem ser repassadas ao cliente.
A análise direta de smart contracts pode ser realizada usando os seguintes métodos (sem entrar em detalhes, pois isso está além do escopo deste artigo):
Análise de código;
Análise de documentação;
Engenharia reversa da arquitetura do projeto com base exclusivamente no código-fonte;
Testes de fuzzing;
Análise estática;
Verificação formal;
Testes mutacionais;
Análise de casos de teste e parâmetros de uso;
Uso de bancos de dados de vulnerabilidades;
Uso de checklists;
Uso de IA e assistentes baseados nela.
Uma questão importante que precisa ser levantada é o registro e a confirmação de vulnerabilidades, pelo menos para vulnerabilidades de alto nível de perigo. O auditor deve fornecer um "PoC" (Proof-of-Concept) como prova e exemplo de exploração da vulnerabilidade encontrada, pois, caso contrário, pode ocorrer uma situação desagradável e a vulnerabilidade não será confirmada pelo cliente ou desenvolvedores com a justificativa "Não pode ser!".
Em seguida, cada auditor forma uma lista de vulnerabilidades encontradas, sem esquecer de atribuir o nível de criticidade da vulnerabilidade a cada descoberta (lembro que os critérios de avaliação de vulnerabilidades foram aprovados em uma etapa anterior). Geralmente, se falarmos diretamente sobre os critérios, as vulnerabilidades podem ser classificadas dependendo do ambiente de operação dos smart contracts e seus riscos. Essa avaliação pode variar de auditoria para auditoria.
Com isso, a etapa principal do projeto é concluída, resumimos em um checklist:
Distribuir responsabilidades entre os auditores e garantir condições para a realização da auditoria;
Apresentar ao cliente o plano de trabalho, os próprios auditores, explicando suas funções;
Definir o procedimento de interação com o cliente e os desenvolvedores em termos de troca de informações;
Escolher a abordagem de auditoria considerando os objetivos, tempo disponível e outras circunstâncias;
Realizar a busca e formar uma lista de vulnerabilidades encontradas.
E novamente adicionamos tudo o que foi descrito à nossa tabela:
Etapa Final
A etapa final começa com a preparação para a reunião final, ou seja, preparamos para demonstrar os bugs encontrados!
Para isso, a equipe de auditores precisa revisar todas as vulnerabilidades encontradas e, durante a discussão, descartar bugs inválidos, remover duplicatas, agrupar vulnerabilidades em uma só, se necessário, e também preparar recomendações para a correção dessas vulnerabilidades, se possível (recentemente, a palavra da moda "mitigação", que significa "redução do risco de vulnerabilidade", entrou em uso).
Finalmente, passamos ao relatório final! Nele, é desejável refletir todas as etapas da auditoria, descrever a arquitetura do sistema, adicionar uma descrição dos riscos descobertos durante o processo, e também adicionar informações sobre as ferramentas utilizadas e seus artefatos, e, claro, não esquecer da lista de vulnerabilidades encontradas.
O momento mais responsável, que todos esperam, chegou! É a realização da reunião de trabalho final com a demonstração das vulnerabilidades encontradas.
É compreensível que tal reunião nem sempre seja possível e, após algum tempo, o cliente simplesmente receberá uma versão preliminar da conclusão da auditoria. Neste caso, o relatório preliminar tem mais requisitos: tudo deve ser cuidadosamente documentado (vulnerabilidades e consequências descritas em detalhes, links para linhas de código, instruções para executar PoC, descrição das configurações do ambiente para as vulnerabilidades encontradas, etc.).
O processo de demonstração e discussão das vulnerabilidades encontradas pode variar, por isso não vou me aprofundar nisso, apenas direi que, em caso de vulnerabilidades críticas (se foram encontradas durante o trabalho), é importante elaborar um plano de ação para sua correção e discutir as possíveis consequências de correções incorretas dessas vulnerabilidades. Geralmente, a correção de vulnerabilidades e a verificação dessas correções podem ocorrer como parte da auditoria atual ou ser a base para a realização de uma nova.
Em alguns casos, se o cliente exigir ou se for regulamentado por seus processos de trabalho, a reunião de trabalho final pode ser oficial, com registro de atas, registro dos presentes e manutenção de sua lista.
Após o recebimento do feedback, inicia-se a preparação da versão final do relatório. Ela deve obrigatoriamente conter informações concretas sobre o escopo, objetivos, prazos da auditoria, seu resultado com a conclusão e conclusões finais, bem como informações sobre o prestador de serviços e o cliente. E o mais importante... um disclaimer de que a auditoria não contém garantias quanto à utilidade, segurança e adequação do modelo de negócios, regime regulatório para o modelo de negócios, bem como quaisquer outras declarações de conformidade dos smart contracts com seu propósito ou ausência de erros neles.
No final, resta apenas enviar o relatório às partes interessadas e publicar este relatório na rede! Se isso for possível, pois é importante não esquecer da confidencialidade.
Resumimos a etapa final em um checklist:
Preparar uma lista de vulnerabilidades com recomendações para sua correção;
Preparar um relatório final preliminar;
Realizar uma reunião de trabalho final e/ou fornecer uma versão preliminar da conclusão da auditoria;
Preparar a versão final do relatório e entregá-lo ao cliente;
Informar o mundo sobre seus sucessos (ou seja, publicar o relatório) e preparar-se para uma nova auditoria!
Resumimos todos os dados em uma única tabela.
Se você leu até o final, ficarei feliz com quaisquer comentários e observações sobre o tema, quero muito melhorar o processo de auditoria! Sucesso a todos!
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, comunidade!
Sou Dmitry, um ex-desenvolvedor de smart contracts (desde 2017) e, desde 2022, atuo como auditor de smart contracts. Este artigo é para todos que se interessam por segurança da informação e, especificamente, pela auditoria de smart contracts, ou pelo processo de auditoria em geral.
Ao final de uma auditoria, duas perguntas sérias podem surgir: "Por que não tivemos tempo para nada?" e "Por que não encontramos nada?". A situação mais assustadora é quando ambas as perguntas surgem simultaneamente. Podemos resumir isso em uma única palavra: "Falha".
Como tentar prevenir o surgimento dessas perguntas? Para responder a isso, tentarei primeiro descrever o processo de auditoria. Por que descrever a auditoria como um processo? Porque a "falha" muitas vezes não ocorre na busca por vulnerabilidades ou no uso de ferramentas, mas sim na parte organizacional.
Naturalmente, tudo depende dos objetivos e do escopo de uma auditoria específica. Se um processo típico de busca por vulnerabilidades é descrito em algum lugar, ele geralmente consiste nas seguintes etapas:
Preparação: Coleta de informações, análise de requisitos, etc.
Análise Estática: Análise do código sem executá-lo.
Análise Dinâmica: Execução do código para observar seu comportamento.
Testes de Penetração: Tentativas de explorar vulnerabilidades encontradas.
Relatório: Documentação das descobertas e recomendações.
Durante a auditoria, a busca por vulnerabilidades é, de fato, uma etapa importante e principal. No entanto, não há menção à preparação! Neste artigo, tentarei descrever um processo típico de auditoria, usando sistemas de smart contracts como exemplo, desde o início até o relatório final, que é dividido em quatro etapas:
Inicial
Preparatória
Principal
Final
Vamos apresentá-las em uma tabela e adicionar o que já sabemos.
Conscientemente, omitirei os aspectos relacionados à avaliação do escopo da auditoria (seja um repositório ou smart contracts já implantados na rede), elaboração de propostas comerciais, definição de prazos e assinatura de contratos (ou seja, a etapa de negociação). Começarei imediatamente a partir do momento em que o cliente e o prestador de serviços (ou seja, nós) concordarem em realizar a auditoria.
Etapa Inicial
Antes de iniciar a análise do sistema de smart contracts, por nosso lado (o prestador de serviços), um responsável pela auditoria deve ser designado. Esta é a primeira coisa a ser feita no início. O responsável pode ser um líder de equipe, um auditor experiente ou um gerente de projeto, o importante é que ele compreenda o processo.
Também, antes do início da auditoria, é desejável definir os canais de comunicação com o cliente (seu representante ou desenvolvedores), seja um chat em um aplicativo de mensagens ou, por exemplo, um escritório específico nas instalações do cliente, onde serão realizadas reuniões de trabalho.
Recomendo discutir e registrar em algum lugar (chat ou papel) as informações sobre os objetivos, escopo, critérios e métodos da auditoria, bem como a composição da equipe de auditoria.
Uma questão importante separada é o acesso à infraestrutura onde os smart contracts são executados. É necessário esclarecer as especificidades do ambiente de execução, seja um blockchain privado ou público, software de nós ou smart contracts pré-compilados que podem ser específicos para um determinado blockchain. Tudo precisa ser esclarecido! E é melhor fazer isso "logo de cara".
Sobre o que mais às vezes se esquece durante a auditoria? É a sua influência direta nos processos do cliente.
Exemplo: Durante suas atividades, os auditores fazem perguntas aos desenvolvedores, e estes estão com o "produção fora do ar" e buscam freneticamente a causa. Portanto, idealmente, deve haver um cronograma flexível para a auditoria, com "janelas" de comunicação previamente alocadas com os desenvolvedores ou o representante do cliente.
Sem feedback dos desenvolvedores, a qualidade da auditoria pode ser prejudicada (e queremos que a auditoria corra bem!).
Auditores qualificados também sabem da existência de um Acordo de Não Divulgação (NDA). No mundo ideal, antes da auditoria, todos os parâmetros de confidencialidade são acordados entre o cliente e o prestador de serviços, e o procedimento para divulgação das vulnerabilidades encontradas é obrigatoriamente aprovado.
E a cereja do bolo da etapa inicial é o esclarecimento por parte dos auditores sobre qual parte do sistema deve ser enfatizada. Se o sistema consiste em dois módulos, e um deles tem documentação completa, coberto por testes, e o segundo "foi finalizado ontem", é lógico focar no módulo "novo", especialmente onde ele interage com o "antigo".
E agora, sobre o que alguns, por circunstâncias, temem falar. O responsável pela auditoria, já na etapa inicial, deve determinar se a auditoria é possível. É possível atingir os objetivos, mesmo que teoricamente? Se a auditoria for inviável (por exemplo, o volume aumentou drasticamente), ou se houver obstáculos significativos que possam afetar a qualidade da auditoria, é melhor comunicar tudo isso com antecedência, e para algumas organizações isso é feito exclusivamente por escrito. Isso pode levar a conflitos, mas estamos falando sobre como NÃO falhar na auditoria.
Da prática pessoal:
Você e sua equipe chegam às instalações do cliente, onde há controle de acesso, e descobrem que a lista de pessoas autorizadas está desatualizada! E dois dos cinco auditores não conseguem passar pelo posto de controle... Se você veio por duas semanas e resolveu essa questão em meio dia, tudo bem, mas e se for por dois dias? Tais questões devem ser sempre resolvidas com antecedência. E é ainda melhor evitar tais deslizes.
Para resumir o acima exposto. Ao final, a etapa inicial se parece com isto:
Designado um responsável pela auditoria;
Definido o procedimento de interação com os desenvolvedores e/ou cliente;
Esclarecidos e confirmados os objetivos e escopo da auditoria;
Acordados os parâmetros de confidencialidade;
Garantido o acesso à infraestrutura (se necessário) e resolvidas as questões organizacionais.
Voltando à nossa tabela, adicionaremos novos dados.
Etapa Preparatória
Se os detalhes da etapa inicial foram acertados e não há obstáculos visíveis, parabéns! Podemos começar. Começar a auditoria em si? Não! Começar a preparar para a auditoria, ou seja, agora algumas palavras sobre a etapa preparatória da auditoria.
Em primeiro lugar, é necessário verificar se, além do código, existe documentação e, se a resposta for "Sim", verificar em que formato. A existência de documentação é uma faca de dois gumes: você pode acreditar que tudo lá é verdade, e isso será um erro fatal. Ter uma ideia do conteúdo da documentação pode ser útil para esclarecer o funcionamento de smart contracts específicos, suas funções e parâmetros. O volume da documentação também é muito importante; se a auditoria dura uma semana, e a documentação leva um mês para ser lida... esperar que você consiga mergulhar nela é um absurdo. Atenção especial deve ser dada a esquemas e diagramas, se houver.
Se a base de código com smart contracts já passou por auditoria, é desejável ter em mãos os relatórios das verificações anteriores. Isso pode ajudar com vetores de ataque e dar uma compreensão do que o grupo de auditoria anterior enfatizou.
Na etapa inicial, um dos focos foi o acesso à infraestrutura; nesta etapa, o foco se desloca diretamente para a estrutura dessa infraestrutura. Agora é necessário não apenas esclarecer o ambiente de execução dos smart contracts (incluindo smart contracts pré-compilados, redes de consenso, privacidade ou publicidade do blockchain, etc.), mas também avaliar os riscos e oportunidades associados a isso.
Primeiro, precisamos aprovar a composição da equipe de auditoria e sua competência geral. Em seguida, escolhemos os métodos adequados para a auditoria e estimamos como podemos aumentar sua eficácia. Por exemplo, a base de código contém várias bibliotecas matemáticas, um ótimo lugar para fuzzing, e, consequentemente, incluímos na equipe de auditoria um especialista que conhece fuzzing como a palma da sua mão.
Em seguida, vale a pena elaborar um plano de cronograma de auditoria; a detalhe do plano deve refletir a área e a complexidade da auditoria. Outra questão que o plano de cronograma resolve é a distribuição de tarefas entre os auditores. Parece que isso é claro para qualquer um, especialmente se a equipe de auditoria for pequena e composta apenas por especialistas experientes, eles podem resolver isso sozinhos. Mas em auditorias de longa duração e quando a equipe de auditores é composta por cinco ou mais especialistas, a questão da distribuição de tarefas deve receber atenção especial.
O que mais é desejável considerar no plano? Reuniões de trabalho. No mundo ideal, a comunicação com os desenvolvedores está disponível 24 horas por dia, eles são amigáveis e correm para responder às suas perguntas ao primeiro chamado. Mas na realidade, é desejável coordenar e adicionar reuniões de trabalho ao plano de cronograma. Durante a auditoria, colete perguntas dos especialistas e, quando houver um número suficiente delas, envie todo o lote aos desenvolvedores para comentários. Isso pode ser feito pessoalmente, online ou em formato híbrido. Também é importante lembrar que o cliente quer ver pelo que pagou, mesmo antes do relatório final, portanto, mais perguntas e mais reuniões de trabalho eficazes!
Se necessário, o plano de cronograma de auditoria deve ser mostrado ao cliente ou seu representante. Todas as perguntas surgidas em relação a tal plano devem ser resolvidas no início.
O que pode faltar no plano? Flexibilidade. Isso é muito importante em auditorias de longa duração. Durante a auditoria, novas circunstâncias podem surgir, que não eram conhecidas antecipadamente e podem afetar o resultado. É importante reagir a elas rapidamente.
Da prática pessoal:
Um grande protocolo, representando uma plataforma de crédito, consistindo em dezenas de smart contracts, uma pilha de parâmetros, módulos de interação com exchanges descentralizadas e pontes... Após uma semana de busca por vulnerabilidades, ficou claro que havia muitas vulnerabilidades críticas, que foram prontamente fornecidas ao cliente. Eles reagiram positivamente. E uma semana depois, a equipe de auditoria apresentou um novo conjunto de vulnerabilidades confirmadas, demonstrando falhas arquitetônicas fundamentais... O protocolo desenvolvido, devido a nuances do blockchain, era inviável. O projeto teve que ser encerrado, mas o cliente foi compreensivo e permaneceu grato, pois os riscos de perda de fundos e reputação no campo público eram maiores para ele do que uma conclusão de auditoria "negativa".
Um exemplo mais simples de imprevistos: uma vez nos colocaram em uma sala onde não havia eletricidade o dia todo devido a alguns trabalhos externos, e nem todos tinham laptops carregados... No final, tivemos que esperar algumas horas até que a eletricidade fosse ligada.
Outra questão que não abordei, mas que também deve ser refletida no plano, são os critérios de vulnerabilidade. Dependendo do cliente, das condições e dos objetivos da auditoria, os critérios podem ser diferentes. Por exemplo:
"Pessoal, procurem apenas críticas, esta é uma versão intermediária."
A fase final desta etapa é a preparação de ferramentas e software especializados. Os membros da equipe de auditoria, com base em suas tarefas, devem preparar as ferramentas necessárias (por exemplo, checklists ou uma base de vulnerabilidades conhecidas) e o software especializado em si (por exemplo, analisadores estáticos, ferramentas de verificação formal ou um LLM local de trabalho).
Por fim, falarei sobre dois pequenos casos que ocorrem na minha prática com extrema raridade, mas que valem a pena mencionar. O primeiro está relacionado à definição do idioma de trabalho para interação (por exemplo, russo ou inglês) e o idioma do relatório (eles também podem diferir). E o segundo caso diz respeito à coordenação com as atividades de outros auditores em caso de auditoria conjunta ou verificação paralela.
Resumimos o checklist para a etapa preparatória:
Verificar a existência, volume e qualidade da documentação (incluindo esquemas, diagramas e relatórios de auditoria anteriores);
Esclarecer as características, parâmetros do ambiente de execução dos smart contracts e sua estrutura;
Elaborar um plano de cronograma detalhado, aprovar a composição da equipe de auditoria e distribuir tarefas;
Definir critérios para vulnerabilidades;
Preparar ferramentas e software especializados.
Voltando ao esquema geral e atualizando-o.
Etapa Principal
Normalmente, o próprio processo de auditoria da base de código é realizado em uma sequência estritamente definida.
No entanto, essa sequência pode mudar dependendo das circunstâncias de uma auditoria específica.
Repito que, em primeiro lugar, é necessário distribuir as responsabilidades entre os membros da equipe de auditoria. Se houver um único especialista, ele, como um homem-orquestra, realiza todo o trabalho sozinho. Se houver vários auditores, há uma alta probabilidade de duplicação de trabalho: por exemplo, cada um executa o analisador estático Slither e todos recebem o mesmo relatório.
A auditoria como processo impõe certos requisitos de concentração, portanto, se houver observadores externos ou acompanhantes, é desejável reduzir sua influência na equipe de auditoria. Talvez isso soe muito trivial, mas: não atrapalhe as pessoas trabalhando! Se você está nas instalações do cliente e na sala ao lado estão quebrando paredes para instalar tomadas – parabéns! Neste caso, o resultado final será menor. O responsável pela auditoria deve garantir as condições adequadas para a realização do trabalho o máximo possível, e aqui os acompanhantes e observadores podem ser muito úteis.
As responsabilidades entre os auditores estão distribuídas, as condições estão garantidas – é hora da primeira reunião de trabalho. Ela pode ocorrer offline e online, em algum chat ou por videoconferência. É mais fácil se reunir online, mas de qualquer forma, é necessário apresentar ao cliente os membros da equipe de auditoria e explicar suas funções. Novamente, imaginemos o mundo ideal onde, além do CEO ou seu representante, estão presentes os desenvolvedores que estão prontos para responder a quaisquer perguntas... Em seguida, o plano de auditoria é apresentado, a tarefa é coordenar e registrar no plano todas as reuniões de trabalho intermediárias e, o mais importante, o procedimento para informar o cliente e os desenvolvedores sobre o andamento da auditoria e as vulnerabilidades encontradas.
A seguir, apresentarei uma tese sobre a troca de informações. Ela não é obrigatória para a equipe de auditoria (devido ao fato de que os processos, estilos e tipos de auditoria podem ser diferentes), mas é recomendado reunir-se periodicamente para trocar informações, para entender como a busca por vulnerabilidades está progredindo e, se necessário, redistribuir tarefas entre os membros da equipe de auditoria. Para o cliente, os meios de troca de informações podem variar de um chat em um aplicativo de mensagens a canais de comunicação seguros especiais; este ponto também precisa ser discutido e aprovado.
Vale a pena falar separadamente sobre vulnerabilidades significativas. Tais vulnerabilidades devem ser repassadas sem demora ao cliente e, se necessário, aos desenvolvedores. Naturalmente, exceto nos casos em que foi acordado que ninguém deveria ser incomodado: "Mostrem todos os bugs, mesmo os críticos, em três semanas".
Uma das situações mais desagradáveis que podem ocorrer em um projeto é a impossibilidade de cumprir as tarefas no prazo. Nesses casos, o líder da auditoria deve informar o cliente com antecedência para determinar o que fazer a seguir. Para não pintar um quadro sombrio, direi que isso pode ser não apenas a interrupção da auditoria, mas apenas uma mudança no plano, um aumento do prazo ou o adiamento da auditoria para outras datas.
Três Abordagens para Auditoria
Chegou a hora de falar sobre as abordagens para a busca de bugs. Destacarei três principais: métodos de "caixa branca", "caixa preta" e "caixa cinza".
Mas antes de passar para as abordagens, vamos lembrar que uma aplicação blockchain típica consiste em pelo menos quatro partes interdependentes:
Plataforma Blockchain (como ambiente de execução de smart contracts)
Pode conter vulnerabilidades de criptografia, consenso, logging, acesso ao gerenciamento de nós, gerenciamento de chaves de nós;
Smart Contracts
Podem conter vulnerabilidades de lógica de execução de processos de negócios, implementação técnica de processos de negócios;
Aplicação de Negócios
Pode conter vulnerabilidades de gerenciamento de chaves, distorção de dados antes ou depois do envio para smart contracts;
Nível Organizacional
Pode conter características que afetam o acesso dos participantes aos artefatos da aplicação blockchain e a atualização do código-fonte.
Um pouco sobre "caixa branca"
Nesta abordagem, há acesso a todas as partes do projeto, à base de código e à documentação do projeto. O objetivo do auditor é, na maioria das vezes, identificar vulnerabilidades antes do lançamento do projeto ou antes da atualização do produto com nova funcionalidade.
O procedimento para esta abordagem consiste em três etapas e se parece com isto:
Análise Preliminar: Entendimento geral da arquitetura e identificação de riscos potenciais.
Análise de Código e Testes: Busca detalhada por vulnerabilidades e desenvolvimento de provas de conceito.
Verificação Final: Revisão manual e uso de ferramentas para garantir cobertura completa.
Na primeira etapa, as seguintes ações são realizadas:
Revisão da arquitetura do projeto;
Análise da documentação do projeto;
Análise geral do código;
Engenharia reversa para analisar a arquitetura do projeto com base exclusivamente no código-fonte;
Desenvolvimento de um ponto de vista independente sobre a arquitetura do projeto;
Identificação de quaisquer deficiências lógicas no design.
O objetivo desta etapa é entender a estrutura geral do projeto e identificar riscos de segurança potenciais.
Na segunda etapa, realizamos as seguintes ações:
Análise principal do código com técnicas de hacking;
Identificação de vulnerabilidades;
Desenvolvimento de Provas de Conceito (Proof-of-Concept, PoC);
Realização de testes de fuzzing;
Uso de ferramentas de verificação formal;
Análise de casos de teste e comentários no código.
O objetivo principal desta etapa é identificar e eliminar a maioria das vulnerabilidades, incluindo aquelas exclusivas de sistemas distribuídos (aka blockchain).
Na terceira etapa, realizamos:
Verificação manual do código usando checklists internos e externos;
Uso de ferramentas de análise estática e bancos de dados de vulnerabilidades.
Aqui, o principal objetivo é garantir uma cobertura abrangente dos vetores de ataque conhecidos.
Como podemos ver, esta abordagem é adequada quando você tem tudo (código e documentação), e o mais importante, tem tempo para realizar todas as ações.
Um pouco sobre "caixa preta"
Nesta abordagem, a verificação começa com a solicitação de todos os dados disponíveis e endereços de smart contracts no blockchain (aka ledger distribuído). Não há código! Ou melhor, você só tem o bytecode implantado na rede.
O procedimento neste caso, no papel, é muito mais simples:
Descompilação do código do nó ou dos smart contracts;
Reconstrução do código-fonte a partir da forma descompilada;
Aplicação de cenários típicos de execução de nós e uso de smart contracts.
Mas pode acontecer, como diz o ditado: "no papel era liso, mas esqueceram dos barrancos". Esta abordagem é extremamente trabalhosa e requer mais tempo para a verificação. Uma verificação abrangente neste caso nem sempre é possível, portanto, recomendo limitar-se à aplicação de cenários típicos.
Um pouco sobre "caixa cinza"
A opção mais comum e prática. Nesta abordagem, o auditor tem acesso parcial às informações do projeto (por exemplo, acesso limitado ao código-fonte, documentação, configurações, ambiente de teste ou API) e tempo limitado. Esta abordagem inclui uma combinação das abordagens de "caixa preta" e "caixa branca", mas sob restrições. Naturalmente, tal abordagem tende mais para a "caixa branca", pois temos algo em mãos.
O objetivo principal nesta abordagem é identificar vulnerabilidades com conhecimento limitado da arquitetura e lógica do projeto. Encontrar ataques que se aproximem o máximo possível das condições e cenários reais. Na maioria das vezes, os vetores de ataque de um usuário privilegiado, integrador ou usuário comum são verificados.
O procedimento (talvez algo precise ser pulado devido à falta de tempo):
Análise da documentação e arquitetura fornecidas;
Análise das partes disponíveis do código-fonte;
Análise das configurações do ambiente de teste;
Estudo das limitações do armazenamento de dados e sistemas externos;
Modelagem de ataques considerando a arquitetura conhecida;
Análise da comunicação de rede e API;
Tentativas de escalonamento de privilégios usando os papéis apresentados;
Aplicação de cenários de exploração típicos e combinados.
Na vida real, o auditor mais frequentemente encontra a "caixa cinza", na vida de um hacker, a "caixa preta", e o líder da auditoria sonha com a "caixa branca".
Busca por Vulnerabilidades
Após a escolha da abordagem, pode-se prosseguir diretamente para a auditoria, especificamente no sentido de buscar vulnerabilidades. A análise da documentação pode ajudar a encontrar vetores de ataque adequados, e as discrepâncias encontradas entre a documentação e o estado atual do sistema também podem ser registradas de certa forma como vulnerabilidades, e as informações sobre elas devem ser repassadas ao cliente.
A análise direta de smart contracts pode ser realizada usando os seguintes métodos (sem entrar em detalhes, pois isso está além do escopo deste artigo):
Análise de código;
Análise de documentação;
Engenharia reversa da arquitetura do projeto com base exclusivamente no código-fonte;
Testes de fuzzing;
Análise estática;
Verificação formal;
Testes mutacionais;
Análise de casos de teste e parâmetros de uso;
Uso de bancos de dados de vulnerabilidades;
Uso de checklists;
Uso de IA e assistentes baseados nela.
Uma questão importante que precisa ser levantada é o registro e a confirmação de vulnerabilidades, pelo menos para vulnerabilidades de alto nível de perigo. O auditor deve fornecer um "PoC" (Proof-of-Concept) como prova e exemplo de exploração da vulnerabilidade encontrada, pois, caso contrário, pode ocorrer uma situação desagradável e a vulnerabilidade não será confirmada pelo cliente ou desenvolvedores com a justificativa "Não pode ser!".
Em seguida, cada auditor forma uma lista de vulnerabilidades encontradas, sem esquecer de atribuir o nível de criticidade da vulnerabilidade a cada descoberta (lembro que os critérios de avaliação de vulnerabilidades foram aprovados em uma etapa anterior). Geralmente, se falarmos diretamente sobre os critérios, as vulnerabilidades podem ser classificadas dependendo do ambiente de operação dos smart contracts e seus riscos. Essa avaliação pode variar de auditoria para auditoria.
Com isso, a etapa principal do projeto é concluída, resumimos em um checklist:
Distribuir responsabilidades entre os auditores e garantir condições para a realização da auditoria;
Apresentar ao cliente o plano de trabalho, os próprios auditores, explicando suas funções;
Definir o procedimento de interação com o cliente e os desenvolvedores em termos de troca de informações;
Escolher a abordagem de auditoria considerando os objetivos, tempo disponível e outras circunstâncias;
Realizar a busca e formar uma lista de vulnerabilidades encontradas.
E novamente adicionamos tudo o que foi descrito à nossa tabela:
Etapa Final
A etapa final começa com a preparação para a reunião final, ou seja, preparamos para demonstrar os bugs encontrados!
Para isso, a equipe de auditores precisa revisar todas as vulnerabilidades encontradas e, durante a discussão, descartar bugs inválidos, remover duplicatas, agrupar vulnerabilidades em uma só, se necessário, e também preparar recomendações para a correção dessas vulnerabilidades, se possível (recentemente, a palavra da moda "mitigação", que significa "redução do risco de vulnerabilidade", entrou em uso).
Finalmente, passamos ao relatório final! Nele, é desejável refletir todas as etapas da auditoria, descrever a arquitetura do sistema, adicionar uma descrição dos riscos descobertos durante o processo, e também adicionar informações sobre as ferramentas utilizadas e seus artefatos, e, claro, não esquecer da lista de vulnerabilidades encontradas.
O momento mais responsável, que todos esperam, chegou! É a realização da reunião de trabalho final com a demonstração das vulnerabilidades encontradas.
É compreensível que tal reunião nem sempre seja possível e, após algum tempo, o cliente simplesmente receberá uma versão preliminar da conclusão da auditoria. Neste caso, o relatório preliminar tem mais requisitos: tudo deve ser cuidadosamente documentado (vulnerabilidades e consequências descritas em detalhes, links para linhas de código, instruções para executar PoC, descrição das configurações do ambiente para as vulnerabilidades encontradas, etc.).
O processo de demonstração e discussão das vulnerabilidades encontradas pode variar, por isso não vou me aprofundar nisso, apenas direi que, em caso de vulnerabilidades críticas (se foram encontradas durante o trabalho), é importante elaborar um plano de ação para sua correção e discutir as possíveis consequências de correções incorretas dessas vulnerabilidades. Geralmente, a correção de vulnerabilidades e a verificação dessas correções podem ocorrer como parte da auditoria atual ou ser a base para a realização de uma nova.
Em alguns casos, se o cliente exigir ou se for regulamentado por seus processos de trabalho, a reunião de trabalho final pode ser oficial, com registro de atas, registro dos presentes e manutenção de sua lista.
Após o recebimento do feedback, inicia-se a preparação da versão final do relatório. Ela deve obrigatoriamente conter informações concretas sobre o escopo, objetivos, prazos da auditoria, seu resultado com a conclusão e conclusões finais, bem como informações sobre o prestador de serviços e o cliente. E o mais importante... um disclaimer de que a auditoria não contém garantias quanto à utilidade, segurança e adequação do modelo de negócios, regime regulatório para o modelo de negócios, bem como quaisquer outras declarações de conformidade dos smart contracts com seu propósito ou ausência de erros neles.
No final, resta apenas enviar o relatório às partes interessadas e publicar este relatório na rede! Se isso for possível, pois é importante não esquecer da confidencialidade.
Resumimos a etapa final em um checklist:
Preparar uma lista de vulnerabilidades com recomendações para sua correção;
Preparar um relatório final preliminar;
Realizar uma reunião de trabalho final e/ou fornecer uma versão preliminar da conclusão da auditoria;
Preparar a versão final do relatório e entregá-lo ao cliente;
Informar o mundo sobre seus sucessos (ou seja, publicar o relatório) e preparar-se para uma nova auditoria!
Resumimos todos os dados em uma única tabela.
Se você leu até o final, ficarei feliz com quaisquer comentários e observações sobre o tema, quero muito melhorar o processo de auditoria! Sucesso a todos!
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
