“Auditado” é a palavra mais superinterpretada deste setor. Ela é tratada como uma propriedade binária de um projeto, quando na verdade é uma afirmação sobre um conjunto específico de arquivos em um momento específico, feita por uma empresa específica, sob um escopo acordado previamente pelas duas partes.
Ler o relatório em vez do selo leva cerca de dez minutos e muda o que você sabe.
Comece pelo escopo, não pelas constatações
Todo relatório crível tem uma seção de escopo, geralmente nas duas primeiras páginas. Ela nomeia o repositório, o hash do commit revisado e a lista de arquivos de contrato dentro do escopo. Esta é a parte mais útil do documento.
O hash do commit importa porque data a revisão com precisão. Qualquer código escrito depois desse commit — inclusive a correção das constatações do próprio relatório — não fez parte do que foi examinado. Um projeto que auditou em março e lançou novas funcionalidades em junho tem código auditado e código não auditado implantados juntos, e só o relatório diz qual é qual.
Leia o que ficou de fora
As seções de escopo também dizem o que não foi revisado, e essa lista muitas vezes é mais interessante que as constatações. Exclusões comuns: o front-end, os scripts de implantação, a infraestrutura off-chain, a configuração de oráculos, o gerenciamento de chaves de administração e qualquer contrato de terceiros do qual o sistema dependa.
Essas exclusões correspondem quase exatamente ao modo como os sistemas de fato falham. Um comprometimento do front-end acontece em uma camada que as auditorias de contrato não cobrem de forma alguma, e o controle das chaves de administração — quem pode atualizar ou pausar — fica frequentemente fora do escopo, ao mesmo tempo em que é o que determina se os fundos podem ser retirados.
Constatações: severidade e o que aconteceu depois
As constatações costumam ser classificadas de críticas a informativas. Duas perguntas importam mais do que a quantidade:
- Cada constatação foi corrigida, reconhecida ou contestada? Os relatórios normalmente registram a resposta do projeto. “Reconhecida” significa que o projeto leu e escolheu não mudar nada — o que pode ser razoável, mas é uma decisão, não uma correção.
- A correção foi revisada de novo? Uma correção escrita depois da revisão e nunca reexaminada é código novo e não auditado na parte mais sensível do sistema.
O que uma auditoria estruturalmente não consegue pegar
Os auditores revisam o código em relação à intenção. Quando a própria intenção é falha, o código pode estar correto e o sistema ainda assim perder dinheiro — isso é uma falha de lógica de negócio, e é a classe com maior probabilidade de atravessar a revisão, porque nada parece errado linha a linha. O ataque de doação à Euler Finance é um registro desse formato.
As auditorias também presumem que o compilador produz o que o código-fonte diz. Quando essa premissa falha — um comprometimento da cadeia de ferramentas —, o código-fonte revisado e o bytecode implantado divergem, como nos registros de reentrância Vyper da Curve Finance.
Uma lista de verificação curta
- Existe um relatório de fato, publicado na íntegra — e não um resumo ou um logotipo?
- Qual commit foi revisado, e o código implantado corresponde a ele?
- O que ficou explicitamente fora do escopo?
- As constatações críticas e altas foram corrigidas, e as correções foram revisadas de novo?
- Existe também um programa de recompensas por falhas, que cobre o código conforme ele muda, em vez de um único instantâneo?
Não é aconselhamento. A Conisec publica apenas para fins informativos. Nada neste artigo é orientação financeira, jurídica, tributária ou de segurança. Confira nas fontes primárias linkadas acima antes de agir com base em qualquer coisa.
