Auditorías de contratos inteligentes: qué detectan y qué se les escapa

Una auditoría de contrato inteligente suele tratarse como un sello de seguridad: auditado significa seguro, sin auditar significa arriesgado. La realidad es más limitada y, a la vez, más útil una vez que se entiende bien. Una auditoría es una revisión estructurada que detecta categorías específicas y conocidas de errores; no es una garantía, y protocolos auditados han seguido perdiendo fondos de usuarios ante exploits. Este artículo explica qué hace realmente una auditoría y dónde están sus límites.

Qué comprueba realmente una auditoría

Una auditoría de contrato inteligente es una revisión manual y automatizada del código de un contrato, realizada normalmente antes del despliegue, que busca patrones de vulnerabilidad conocidos: errores de reentrancia, desbordamiento y subdesbordamiento de enteros (integer overflow/underflow), fallos de control de acceso que permiten que una dirección equivocada llame a una función privilegiada, y errores de lógica que se apartan del propósito declarado del contrato. Los auditores también contrastan el contrato con la documentación propia del proyecto, buscando puntos donde el código hace algo distinto de lo que dice hacer.

Dado que los contratos inteligentes se ejecutan exactamente como están escritos y son difíciles de modificar una vez desplegados, esta categoría de error resulta inusualmente grave: un fallo que una aplicación tradicional podría parchear discretamente puede, en un contrato en producción que gestiona valor real, ser explotado en el mismo momento en que se descubre. Esa es la razón principal por la que las auditorías existen como práctica diferenciada en lugar de integrarse en la revisión de código habitual.

Qué detectan las auditorías de forma fiable

Las clases de vulnerabilidad establecidas y bien entendidas son donde las auditorías se ganan su reputación. La reentrancia —cuando un contrato malicioso vuelve a llamar al contrato auditado antes de que termine su primera llamada, vaciando fondos mediante retiros repetidos— es un caso de manual que los auditores experimentados comprueban de forma rutinaria, precisamente porque causó algunos de los exploits más tempranos y costosos del sector. Las brechas de control de acceso, las llamadas externas sin verificar y los problemas de aleatoriedad predecible entran en la misma categoría: modos de fallo conocidos con métodos de detección conocidos.

Para estas categorías, una auditoría competente reduce el riesgo de forma significativa. Un contrato que ha pasado por la revisión de una firma de prestigio tiene, de forma medible, menos probabilidades de fallar ante un patrón de ataque conocido que uno que no lo ha hecho.

Qué se les escapa a las auditorías

Las auditorías son mucho menos fiables frente a exploits novedosos, interacciones complejas entre varios contratos y fallos de diseño económico que no tienen nada que ver con un error de programación. Un contrato puede estar implementado exactamente según su especificación y aun así ser explotable porque la propia especificación tiene un fallo: un oráculo de precios que puede manipularse, una estructura de incentivos que premia un comportamiento que sus diseñadores no anticiparon, o un mecanismo de gobernanza que un atacante con suficientes recursos puede capturar temporalmente. Nada de esto son errores en el sentido tradicional, y ninguna cantidad de revisión de código detecta un fallo de diseño que el auditor no esté buscando específicamente.

Las auditorías también son una fotografía puntual. Un contrato puede auditarse y luego modificarse sin una revisión de seguimiento, o combinarse con otros contratos de formas que la auditoría original nunca consideró. La característica central de DeFi —la componibilidad sin permisos, donde cualquier contrato puede llamar a cualquier otro— es también la razón por la que la auditoría de un contrato aislado no puede garantizar la seguridad una vez que empieza a interactuar con contratos que nadie revisó de forma conjunta.

Qué significa esto en la práctica

Conviene tratar una auditoría como una reducción significativa del riesgo frente a categorías conocidas de errores, no como una prueba de seguridad. Un informe de auditoría publicado merece leerse, no solo citarse: hay que comprobar qué alcance cubrió realmente, si los hallazgos se resolvieron o solo se reconocieron, y con qué antigüedad se realizó en relación con el código actual, posiblemente modificado. Una auditoría reduce el riesgo; no lo elimina, y ningún proyecto legítimo debería dar a entender lo contrario.