Antes de fijarte en el sello, lee el alcance, el hash del commit, la dirección desplegada, las definiciones de gravedad, los hallazgos sin resolver y las limitaciones de las pruebas. Una auditoría solo resulta útil si cubre el código y la configuración que realmente vas a usar.
Comprende las piezas del sistema#
Los informes son revisiones realizadas en un momento concreto. Pueden excluir el front end, los oráculos, los puentes, las operaciones administrativas y los supuestos económicos que dominan el riesgo real.
Marco para tomar decisiones#
Crea un mapa de riesgo de una página: defectos del código, roles privilegiados, dependencias externas, posibilidad de actualización y respuesta a incidentes. El informe aporta datos a ese mapa, pero no lo sustituye.
Hazlo siguiendo una secuencia controlada#
- Relaciona el commit del repositorio con las direcciones de los contratos. Hazlo antes de confiar valor o autoridad de firma y verifica después el estado resultante.
- Comprueba qué componentes y cadenas quedaron excluidos. Contrasta dominio, dirección, red y permisos exactos con una fuente oficial independiente.
- Lee cada hallazgo crítico o de gravedad alta y su estado de corrección. Compara la versión afectada y el remedio con la documentación exacta.
- Confirma que las correcciones volvieron a probarse y no solo se reconocieron. Busca evidencia del retest y del commit revisado.
- Revisa las notas sobre centralización, actualizaciones y gestión de claves. Verifica quién conserva cada facultad y qué demora o control la limita.
Errores habituales#
- Contar auditorías en vez de leer su alcance. Un número o un logotipo puede copiarse y no demuestra que el despliegue actual esté cubierto.
- Tratar “resuelto” como prueba de que la corrección desplegada coincide. Omite la relación entre commit, contrato y prueba posterior.
- Ignorar hallazgos informativos que revelan poder administrativo. Aunque no sean errores de código, pueden describir una autoridad capaz de cambiar el riesgo.
- Suponer que la ausencia de hallazgos significa ausencia de vulnerabilidades. Toda revisión tiene límites de tiempo, alcance y métodos.
Un resultado correcto no consiste simplemente en completar una operación o ajuste. Debe poder verificarse, reproducirse y recuperarse de forma independiente si falla el servicio circundante.
Confirma el resultado#
No juzgues la evaluación solo porque la interfaz muestre un mensaje de éxito. Usa pruebas que todavía puedan comprobarse después de cerrar la página.
| Punto de control | Prueba | Condición para detenerse |
|---|---|---|
| Relacionar el commit del repositorio y las direcciones de contrato | URL o dirección de contrato exacta cotejada con documentación oficial | Contar auditorías en vez de leer el alcance |
| Comprobar qué componentes y cadenas quedaron excluidos | Captura fechada o registro onchain con los datos sensibles eliminados | Tratar “resuelto” como prueba de que coincide el despliegue |
| Leer cada hallazgo crítico o alto y su corrección | Captura fechada o registro onchain con los datos sensibles eliminados | Ignorar hallazgos informativos sobre poder administrativo |
Conserva hashes de transacción, números de caso oficiales o capturas fechadas cuando ayuden a documentar la auditoría, pero excluye frases semilla, claves privadas y códigos de autenticación.
Preguntas frecuentes#
¿Qué significa “reconocido” en una auditoría?
Normalmente indica que el equipo acepta el riesgo sin modificarlo. Lee la definición exacta del estado utilizada por el auditor.
¿Los programas de recompensas por fallos son mejores que las auditorías?
Son complementarios: las auditorías revisan un alcance definido y los programas de recompensas invitan a realizar pruebas externas continuas.
¿Cuándo es demasiado antigua una auditoría?
La antigüedad importa menos que saber si el código, la configuración o las dependencias cambiaron después del commit revisado.
Guías relacionadas#
Fuentes#
Aviso de riesgo: Las acciones con criptoactivos pueden ser irreversibles. Nunca compartas una frase semilla, clave privada, contraseña o código de autenticación, y verifica por separado cada dominio y solicitud de la wallet.
Criterio editorial
Esta guía es educativa y se apoya en fuentes. Los controles de seguridad, las reglas de los exchanges y los requisitos legales pueden cambiar; confirma los pasos importantes en fuentes oficiales.
