Auditorías de seguridad: qué te dice realmente un informe de auditoría
«Auditado por» es una de las insignias más habituales en el mundo cripto. Aparece en sitios web, en presentaciones para inversores y en lanzamientos de tokens, a menudo como si zanjara la cuestión de si algo es seguro. No lo hace, pero un informe de auditoría real, bien leído, te cuenta muchísimo. El truco está en saber qué buscar.
Qué es una auditoría
Una auditoría de seguridad es una revisión, acotada en el tiempo, de un código concreto realizada por una empresa externa. Los auditores leen el código, lo prueban, intentan romperlo y documentan lo que encuentran. En los contratos inteligentes, eso suele significar revisión manual más herramientas automatizadas; en las billeteras, puede incluir las aplicaciones, la criptografía, los servidores con los que se comunican y la forma en que todo encaja.
El resultado es un informe: qué se revisó, cuándo, qué se encontró, qué gravedad tenía cada hallazgo y si el equipo lo corrigió.
Tres expresiones de esa descripción importan más que el resto: código concreto, acotada en el tiempo y qué se encontró.
Lee primero el alcance
El alcance indica exactamente qué examinaron los auditores: normalmente repositorios, contratos o componentes concretos, a menudo fijados a un commit determinado.
Ahí es donde se desmoronan la mayoría de las afirmaciones engañosas de «auditado». Un proyecto puede haber auditado un único contrato pequeño y anunciar todo el protocolo como auditado. Una billetera puede haber sometido a revisión sus contratos inteligentes mientras que la aplicación que realmente construye y firma tus transacciones nunca se examinó. Si aquello en lo que confías no está dentro del alcance, la auditoría no dice nada sobre ello.
Pregúntate: ¿cubre el alcance las partes que tocan mis fondos?
Comprueba la fecha y la versión
Una auditoría describe el código tal como era el día en que se revisó. Todo lo que se haya publicado después (nuevas funciones, nuevas cadenas, refactorizaciones) queda fuera de ella, salvo que se haya vuelto a revisar.
Es normal: el software cambia constantemente. Pero significa que una auditoría de hace dos años sobre un proyecto que avanza rápido es un documento histórico. Las preguntas útiles son cuándo se hizo, qué versión cubrió y si los cambios importantes posteriores han tenido su propia revisión.
En los contratos inteligentes hay un matiz adicional: si un contrato es actualizable, el código que se ejecuta hoy puede no ser el que se auditó. Quién controla las actualizaciones importa tanto como la propia auditoría.
Lee los hallazgos, no solo el resumen
Los informes clasifican los hallazgos por gravedad (normalmente crítica, alta, media, baja e informativa) y registran si cada uno se corrigió, se reconoció o se dejó tal cual.
- Los hallazgos críticos y altos son los que podrían hacer perder fondos. ¿Hubo alguno? ¿Se corrigieron y se volvieron a comprobar?
- «Reconocido» no es «corregido». Significa que el equipo aceptó el riesgo. A veces es razonable; lee por qué.
- Cero hallazgos no es automáticamente una buena noticia. Puede significar un código excelente, o un alcance reducido y un encargo corto.
- La nueva verificación importa. Un buen informe dice que los auditores verificaron las correcciones, no solo que el equipo afirmó haberlas hecho.
Lo que una auditoría no puede decirte
Incluso una auditoría exhaustiva tiene límites que conviene decir claramente:
- Es una muestra de atención, no una prueba. Los auditores encuentran muchos errores, pero no todos. Protocolos auditados han sido explotados.
- Cubre el código, no las operaciones. Cómo se almacenan las claves, quién puede desplegar, cómo gestiona el equipo un incidente: normalmente todo eso queda fuera del alcance.
- No cubre el diseño económico, salvo que estuviera explícitamente en el alcance. Un contrato puede funcionar exactamente como está escrito y aun así ser explotable a través de precios, incentivos u otros protocolos.
- No cubre lo que instalas. Una auditoría del código fuente no dice nada de una aplicación falsa con el mismo nombre. Las compilaciones reproducibles son lo que conecta el código publicado con el software que realmente ejecutas.
Señales de alarma en las afirmaciones de «auditado»
- No hay enlace al informe real, o el informe solo está alojado por el propio proyecto.
- Un auditor al que no puedes encontrar, o cuyo sitio no menciona el encargo.
- Un alcance que no coincide con lo que se está promocionando.
- Hallazgos de gravedad alta sin corregir descritos como «abordados».
- Una sola auditoría de hace años, sobre un producto que ha cambiado por completo desde entonces.
Cómo lo aborda SSP
El código de SSP es de código abierto, así que cualquiera puede leerlo; pero código abierto y código auditado no son lo mismo, y los tratamos por separado.
Halborn, una empresa de seguridad independiente, ha auditado los contratos inteligentes ERC-4337 de SSP y, de forma conjunta, la extensión SSP Wallet, la aplicación SSP Key y SSP Relay. Ambos informes son públicos en el sitio de Halborn, sin hallazgos críticos ni altos, y los hallazgos bajos e informativos se abordaron. Nuestro resumen de auditorías de 2025 detalla el alcance y las fechas de cada encargo.
Las mismas salvedades se nos aplican a nosotros que a cualquiera. Esas auditorías cubren el código tal como era cuando se revisó; las funciones y cadenas añadidas desde entonces no están cubiertas por ellas, así que indicamos qué tipo de revisión ha tenido el código más reciente en lugar de estirar una insignia antigua para que lo cubra.
El resumen honesto
Una auditoría es una evidencia, no una garantía. Te dice que un código concreto, en un momento concreto, fue revisado por una empresa concreta, y qué encontró.
Lee el alcance, comprueba la fecha y la versión, mira las gravedades y cómo se resolvieron, y busca el informe en el propio sitio del auditor. Haz eso, y «auditado» deja de ser una insignia y empieza a ser información.
