¿Por qué un contrato auditado no puede garantizar una seguridad absoluta?
En el mundo Web3, cuando ven que un proyecto afirma que «sus contratos inteligentes han superado una auditoría de seguridad», muchas personas piensan de inmediato: como ya los ha revisado una entidad profesional, los fondos deberían estar relativamente seguros.
Pero aquí hay una diferencia importante:
Superar una auditoría significa que el código incluido en un alcance específico ha pasado una revisión de seguridad; no significa que todo el proyecto esté libre de riesgos.
Comprender esto es clave para entender el verdadero valor de un informe de auditoría.
1. Una auditoría revisa un alcance específico, no todos los problemas posibles
Las auditorías de contratos inteligentes suelen realizarse sobre una versión específica del código, con un alcance acordado y en un momento determinado.
Si la auditoría no abarcó algún módulo o si el proyecto modificó el código después de la revisión, el informe original no puede demostrar automáticamente que esas partes nuevas o modificadas también sean seguras.
Por lo tanto, al leer un informe de auditoría, primero hay que comprobar lo siguiente:
¿Quién realizó la auditoría?
¿A qué dirección del contrato, versión del código o registro de cambios corresponde el informe?
¿Qué módulos abarcó concretamente la auditoría?
¿Se han corregido los problemas señalados en el informe y se han vuelto a revisar?
¿El proyecto realizó actualizaciones importantes después de la auditoría?
El informe de auditoría debe corresponder al código realmente desplegado.
De lo contrario, aunque el informe sea auténtico y válido, quizá no permita demostrar suficientemente la seguridad de la versión que se está ejecutando actualmente.
2. Que el código no tenga vulnerabilidades evidentes no significa que la lógica del negocio no presente problemas
Una auditoría no solo debe comprobar si el código contiene vulnerabilidades comunes, sino también entender si el diseño del contrato se ajusta a lo previsto.
Por ejemplo, el código de un protocolo de préstamos podría no tener vulnerabilidades evidentes de reentrada, pero la valoración de las garantías, las condiciones de liquidación o el mecanismo de cálculo de los intereses aún podrían presentar fallos de diseño.
Es posible que estos problemas no se manifiesten como vulnerabilidades de código en el sentido tradicional, pero podrían ocasionar pérdidas imprevistas a los usuarios.
Para determinar si un proyecto es seguro, no basta con preguntar:
«¿Se han encontrado vulnerabilidades?»
También hay que preguntar:
«Aunque el código funcione según lo previsto, ¿es razonable el diseño en sí?»
3. Quién tiene permisos puede ser más importante que el código en sí
Algunos contratos incluyen permisos de administrador, de actualización, de pausa o de modificación de parámetros.
Estos mecanismos pueden tener usos legítimos, como responder a vulnerabilidades urgentes o ajustar los parámetros del protocolo. Sin embargo, también implican que ciertas acciones clave siguen dependiendo de direcciones específicas o de procesos de gobernanza.
Es necesario comprobar lo siguiente:
¿Puede el administrador modificar parámetros clave?
¿Se puede actualizar el contrato y quién debe aprobar la actualización?
¿Hay un bloqueo temporal, firmas múltiples u otras restricciones de permisos?
¿Quién tiene autoridad para pausar las transacciones, congelar activos o cambiar configuraciones clave?
¿Los cambios de permisos quedan registrados de forma pública y verificable?
Hay que tener en cuenta que la existencia de permisos de administrador no significa que el proyecto sea necesariamente inseguro; del mismo modo, la ausencia de permisos de administrador evidentes no significa que el sistema sea absolutamente seguro.
Lo fundamental es entender los límites reales de esos permisos y cómo están restringidos.
4. Las dependencias externas también pueden introducir riesgos
Los contratos inteligentes no siempre funcionan de forma independiente.
Algunos protocolos dependen de oráculos para obtener datos de precios, de otros contratos para realizar transacciones o de infraestructuras entre cadenas para transmitir mensajes.
Aunque los contratos principales hayan sido auditados, las dependencias externas aún pueden sufrir fallos, errores de configuración, anomalías en los datos o incidentes de seguridad.
Por ejemplo, un protocolo de préstamos puede depender de datos de precios externos para calcular el índice de colateralización. Si los datos de precios presentan anomalías, podrían producirse liquidaciones incorrectas u otros riesgos, aunque el contrato de préstamos no tenga vulnerabilidades de código evidentes.
Por lo tanto, al evaluar la seguridad, también es necesario saber de qué depende el proyecto y qué consecuencias tendría un fallo de esas dependencias.
5. Las condiciones de seguridad aún pueden cambiar después del lanzamiento
Una auditoría no es una garantía de seguridad permanente.
Las actualizaciones de contratos, los cambios de permisos, los ajustes de servicios externos y las variaciones del entorno de mercado pueden modificar la estructura de riesgos existente.
Además, un informe de auditoría refleja los resultados de una revisión realizada en un momento y con un alcance específicos; no puede abarcar todos los métodos de ataque que puedan surgir en el futuro.
En el caso de los contratos actualizables, es especialmente importante prestar atención al historial de actualizaciones, a la dirección de la implementación actual y a si se realizaron nuevas comprobaciones de seguridad después de la actualización.
En los protocolos que llevan mucho tiempo en funcionamiento, también conviene seguir los avisos de seguridad, las divulgaciones de vulnerabilidades, las transacciones anómalas y los cambios en configuraciones clave.
6. ¿Cómo deberían interpretar los usuarios comunes los informes de auditoría?
Puedes formarte tu propio criterio teniendo en cuenta cinco aspectos:
Primero, comprueba si el informe es auténtico. ¿Puedes encontrarlo en los canales oficiales de la firma auditora?
Segundo, comprueba si el informe corresponde al proyecto. ¿Coincide la versión del código auditada con la versión realmente desplegada?
Tercero, comprueba si se ha dado seguimiento a los problemas. ¿Se han corregido los problemas detectados y se han verificado las correcciones?
Cuarto, comprueba si los permisos son transparentes. ¿Qué facultades tienen el administrador, quienes realizan actualizaciones y quienes participan en la gobernanza?
Quinto, comprueba si los riesgos se gestionan de forma continua. Después del lanzamiento, ¿existen mecanismos continuos de supervisión, divulgación y respuesta?
Estas cinco preguntas no pueden demostrar que un proyecto sea absolutamente seguro, pero sí pueden ayudarte a evitar interpretar «ha superado una auditoría» como «no tiene riesgos».
Por último
La auditoría es una parte importante de la seguridad de los contratos inteligentes, pero no es el punto final.
Un sistema de seguridad verdaderamente confiable requiere una combinación de revisión del código, un diseño empresarial razonable, una gestión transparente de los permisos, el control de los riesgos de las dependencias externas y un mantenimiento continuo después del lanzamiento.
No preguntes únicamente si el proyecto ha sido auditado; pregunta también qué se auditó, qué versión se revisó y qué cambios se produjeron después de la auditoría.
En el ámbito de los activos digitales, la evaluación de la seguridad no debería basarse únicamente en los mensajes promocionales de un proyecto, sino en pruebas que puedan verificarse de forma independiente.
Aviso de seguridad: un informe de auditoría es solo una parte de la evaluación de riesgos; no constituye asesoramiento de inversión ni garantiza la seguridad del capital.
