Leia o escopo, o hash do commit, o endereço implantado, as definições de gravidade, as falhas não resolvidas e as limitações do teste antes de olhar o selo. Uma auditoria só é útil quando cobre o código e a configuração que você realmente usará.
Entenda as partes envolvidas#
Relatórios são revisões feitas em um momento específico. Eles podem excluir front-end, oráculos, bridges, operações administrativas e premissas econômicas que dominam o risco real.
Monte um mapa de risco#
Crie uma página com defeitos de código, papéis privilegiados, dependências externas, capacidade de upgrade e resposta a incidentes. O relatório alimenta esse mapa, mas não o substitui.
Leia em uma sequência controlada#
- Associe o commit do repositório e os endereços dos contratos. Confirme que a versão auditada corresponde exatamente ao código implantado.
- Confira quais componentes e redes ficaram fora do escopo. Não atribua à auditoria cobertura que o próprio documento exclui.
- Leia cada achado crítico e alto e seu estado de correção. Entenda impacto, exploração possível e resposta da equipe.
- Confirme que as correções foram retestadas, e não apenas reconhecidas. “Resolvido” precisa apontar para código e versão verificados pelo auditor.
- Revise notas sobre centralização, upgrades e gestão de chaves. Achados informativos podem revelar poderes administrativos importantes.
Armadilhas comuns#
- Contar auditorias sem ler o escopo. Vários selos podem cobrir componentes antigos ou irrelevantes.
- Tratar “resolvido” como prova de que a correção implantada coincide. Compare commit, endereço e relatório de reteste.
- Ignorar achados informativos que revelam poder administrativo. Uma chave capaz de pausar ou atualizar muda o modelo de confiança.
- Presumir que ausência de achados significa ausência de vulnerabilidades. Toda revisão tem limites de tempo, método e cobertura.
Uma leitura segura não termina em um selo. O resultado precisa ser verificável, reproduzível e relacionado ao sistema que está realmente em uso.
Confirme o resultado da leitura#
Não avalie a auditoria apenas pela mensagem ou pelo badge do projeto. Use evidências que continuem verificáveis depois de fechar a página.
| Ponto de controle | Evidência | Condição para parar |
|---|---|---|
| Associar commit e contratos | URL e endereço comparados à documentação | A análise só conta quantas auditorias existem |
| Conferir exclusões de escopo | Relatório e componentes listados | “Resolvido” é aceito sem confirmar a implantação |
| Ler falhas críticas e altas | Achados e estado de correção preservados | Notas de poder administrativo são ignoradas |
Guarde relatórios, hashes de commit, endereços e capturas datadas quando ajudarem a documentar a análise, mas exclua frases-semente, chaves privadas e códigos de autenticação.
Perguntas frequentes#
O que significa “acknowledged” em um relatório?
Normalmente significa que a equipe reconhece o risco sem alterá-lo. Leia a definição exata de status usada pelo auditor.
Bug bounty é melhor que auditoria?
São complementares: auditorias são revisões com escopo, enquanto programas de recompensa convidam testes externos contínuos.
Quando uma auditoria fica antiga demais?
A idade importa menos que mudanças no código, na configuração ou nas dependências após o commit revisado.
Guias relacionados#
Fontes#
Aviso de risco: Ações com criptomoedas podem ser irreversíveis. Nunca compartilhe frase-semente, chave privada, senha ou código de autenticação e verifique cada domínio e solicitação da carteira de forma independente.
Padrão editorial
Este guia é educativo e baseado em fontes. Controles de segurança, regras das corretoras e exigências legais podem mudar; confirme etapas importantes em fontes oficiais.
