«Auditado» es la palabra que más se sobreinterpreta en este sector. Se trata como una propiedad binaria de un proyecto, cuando en realidad es una afirmación sobre un conjunto concreto de archivos en un momento concreto, hecha por una empresa concreta, bajo un alcance que ambas partes acordaron de antemano.
Leer el informe en lugar del sello lleva unos diez minutos y cambia lo que sabes.
Empieza por el alcance, no por los hallazgos
Todo informe solvente tiene una sección de alcance, normalmente en las dos primeras páginas. Identifica el repositorio, el hash del commit revisado y la lista de archivos de contrato incluidos. Es la parte más útil del documento.
El hash del commit importa porque data la revisión con precisión. Todo el código escrito después de ese commit —incluida la corrección de los propios hallazgos del informe— no formó parte de lo examinado. Un proyecto que se auditó en marzo y publicó nueva funcionalidad en junio tiene código auditado y código sin auditar desplegados a la vez, y solo el informe te dice cuál es cuál.
Lee qué quedó excluido
Las secciones de alcance también indican qué no se revisó, y esa lista suele ser más interesante que los hallazgos. Exclusiones habituales: la interfaz, los scripts de despliegue, la infraestructura fuera de la cadena, la configuración del oráculo, la gestión de las claves de administración y cualquier contrato de terceros del que dependa el sistema.
Esas exclusiones se corresponden casi exactamente con la forma en que los sistemas fallan en la práctica. Un compromiso de la interfaz ocurre en una capa que las auditorías de contratos no cubren en absoluto, y el control de las claves de administración —quién puede actualizar o pausar— queda con frecuencia fuera de alcance siendo lo que determina si pueden sustraerse fondos.
Hallazgos: gravedad, y qué pasó después
Los hallazgos suelen graduarse de críticos a informativos. Dos preguntas importan más que el recuento:
- ¿Cada hallazgo se corrigió, se aceptó o se discutió? Los informes normalmente recogen la respuesta del proyecto. «Aceptado» significa que el proyecto lo leyó y decidió no cambiar nada, lo cual puede ser razonable, pero es una decisión, no una corrección.
- ¿Se volvió a revisar la corrección? Una corrección escrita después de la revisión y nunca reexaminada es código nuevo sin auditar en la parte más sensible del sistema.
Qué no puede detectar una auditoría por su propia estructura
Quienes auditan revisan el código frente a la intención. Cuando la intención misma es defectuosa, el código puede ser correcto y el sistema perder dinero igualmente: eso es un defecto de lógica de negocio, y es la clase con más probabilidades de sobrevivir a una revisión, porque nada parece mal línea a línea. El ataque por donación a Euler Finance es un registro de esa forma.
Las auditorías también dan por supuesto que el compilador produce lo que dice el código fuente. Cuando ese supuesto falla —un compromiso de la cadena de herramientas—, el código fuente revisado y el bytecode desplegado divergen, como en los registros de reentrada por el compilador Vyper en Curve Finance.
Una lista breve de comprobación
- ¿Existe siquiera un informe, publicado íntegro, y no un resumen o un logotipo?
- ¿Qué commit se revisó, y coincide con él el código desplegado?
- ¿Qué quedó explícitamente fuera de alcance?
- ¿Se corrigieron los hallazgos críticos y altos, y se volvieron a revisar las correcciones?
- ¿Hay además un programa de recompensas por fallos, que cubre el código a medida que cambia en lugar de una única instantánea?
No es asesoramiento. Conisec informa solo a título informativo. Nada de este artículo es asesoramiento financiero, jurídico, fiscal ni de seguridad. Verifícalo con las fuentes primarias enlazadas más arriba antes de actuar.
