Auditorías de seguridad

¿Qué son las auditorías de seguridad en el sector cripto?

Las auditorías de seguridad en el sector cripto son revisiones estructuradas de sistemas blockchain, contratos inteligentes, carteras, protocolos, bridges, dApps e infraestructuras para detectar vulnerabilidades antes de que los atacantes puedan explotarlas.

En pocas palabras, una auditoría de seguridad es una inspección profesional del código cripto, la arquitectura, las hipótesis, los permisos y los controles operativos.

Su objetivo es identificar errores, debilidades de diseño, privilegios inseguros, vías de ataque económico y riesgos de integración antes de que se expongan fondos reales de los usuarios.

Las auditorías de seguridad son especialmente importantes en el sector cripto porque los contratos inteligentes pueden custodiar grandes cantidades de valor y las transacciones de blockchain suelen ser difíciles o imposibles de revertir una vez confirmadas.

Un error de software convencional puede provocar interrupciones del servicio o pérdida de datos, pero un error en un contrato inteligente puede causar la pérdida directa de tokens, el bloqueo de fondos, fallos de gobernanza o de liquidación, o el robo de liquidez.

La guía oficial de Ethereum sobre seguridad de contratos inteligentes explica que las auditorías son útiles, pero no deben considerarse una solución infalible.

Esto significa que una auditoría de seguridad es una importante capa de defensa, no una garantía de que un protocolo sea completamente seguro.

Un proceso sólido de seguridad cripto combina diseño seguro, pruebas, revisión de código, auditorías, métodos formales, monitorización, programas de recompensas por errores, respuesta a incidentes y una gestión cuidadosa de las actualizaciones.

Definición sencilla de auditorías de seguridad

Las auditorías de seguridad son revisiones detalladas que buscan debilidades en sistemas cripto antes de su implementación o de actualizaciones importantes.

En el caso de los contratos inteligentes, una auditoría suele revisar el código fuente, la lógica empresarial, los controles de acceso, la contabilidad de tokens, el uso de oráculos, la capacidad de actualización, el comportamiento de las comisiones de gas y los patrones de vulnerabilidad conocidos.

Una auditoría de un protocolo completo también puede revisar riesgos del frontend, servicios del backend, claves de administración, controles multisig, diseño de bridges, infraestructura de validadores, procesos de gobernanza y planes de monitorización.

Un informe de auditoría de seguridad suele clasificar los hallazgos por gravedad, explicar los riesgos, recomendar correcciones e indicar si el equipo ha solucionado cada problema o ha reconocido que existe.

Las auditorías ayudan a usuarios, desarrolladores, inversores y colaboradores del ecosistema a entender si un proyecto ha tomado medidas razonables para reducir riesgos evitables.

Sin embargo, una auditoría no demuestra que un protocolo esté libre de riesgos.

Solo indica que un ámbito concreto fue revisado por unos auditores determinados durante un periodo específico.

Por qué son importantes las auditorías de seguridad en el sector cripto

Las auditorías de seguridad son importantes porque los sistemas cripto suelen gestionar activos directamente mediante código.

Un contrato de préstamos DeFi puede custodiar garantías y posiciones de deuda.

Un pool de liquidez puede contener tokens aportados por los usuarios.

Un bridge puede controlar activos envueltos entre distintas cadenas.

Un contrato de staking puede gestionar la delegación a validadores y el cálculo de recompensas.

Un contrato de gobernanza puede controlar actualizaciones, fondos de tesorería y parámetros del protocolo.

Si alguno de estos sistemas tiene una vulnerabilidad grave, los atacantes podrían vaciar fondos o dañar permanentemente la confianza.

Las auditorías de seguridad reducen la probabilidad de que errores evidentes y de gran impacto lleguen al entorno de producción.

También ayudan a los equipos a mejorar la documentación, aclarar hipótesis y preparar procedimientos de implementación más seguros.

Qué suele revisar una auditoría de seguridad cripto

Una auditoría de seguridad cripto suele comenzar con la documentación del proyecto y su modelo de amenazas.

Los auditores necesitan entender qué debería hacer el protocolo antes de evaluar si el código se comporta de forma segura.

A continuación, revisan línea por línea el código de los contratos inteligentes.

Comprueban que los saldos se registren correctamente, los permisos estén limitados, las llamadas externas sean seguras y se contemplen los casos extremos.

También prueban si se puede abusar del sistema mediante reentradas, manipulación de precios, aleatoriedad deficiente, errores con números enteros, repetición de firmas, denegación de servicio, actualizaciones inseguras o fallos en los controles de acceso.

La página oficial de consideraciones de seguridad de Solidity advierte que las recomendaciones sobre seguridad de contratos inteligentes nunca pueden ser exhaustivas, ya que siguen apareciendo nuevos riesgos y patrones.

Por eso, las auditorías requieren tanto listas de comprobación conocidas como un análisis adversarial creativo.

Una buena auditoría no solo pregunta si el código funciona, sino también cómo podría fallar en condiciones hostiles.

Auditorías de seguridad frente a revisiones de código

Una revisión de código comprueba si el código es legible, correcto, fácil de mantener y coherente con los estándares de desarrollo.

Una auditoría de seguridad se centra más a fondo en cómo se puede atacar, manipular, eludir o utilizar indebidamente el código.

Ambas son útiles, pero no son lo mismo.

Un revisor de código convencional puede preguntarse si una función es clara y fácil de entender.

Un auditor de seguridad se pregunta si esa función puede explotarse mediante entradas inusuales, un orden inesperado de llamadas, abuso de la gobernanza, manipulación de oráculos o interacciones maliciosas con contratos.

Los equipos cripto deberían realizar revisiones internas de código antes de contratar auditores externos.

Los auditores externos no deberían ser los primeros en leer código inacabado.

Las auditorías suelen dar mejores resultados cuando el equipo ya ha probado, documentado y depurado el código.

Auditorías de seguridad frente a verificación formal

La verificación formal utiliza métodos matemáticos para demostrar que el código cumple propiedades específicas bajo unas hipótesis definidas.

Una auditoría de seguridad tiene un alcance más amplio y puede incluir revisión manual, análisis asistido por herramientas, razonamiento económico, revisión de arquitectura y evaluación de riesgos de implementación.

La verificación formal puede ser muy útil para propiedades críticas, como la conservación de los saldos, las reglas de autorización o el mantenimiento de invariantes.

Sin embargo, solo demuestra las propiedades que se han especificado.

Si la especificación es incompleta o incorrecta, la prueba puede no proteger frente al riesgo real.

Las auditorías y la verificación formal funcionan mejor juntas.

Los auditores pueden ayudar a identificar qué propiedades son importantes, mientras que los métodos formales pueden aportar más confianza en que se cumplen.

En los protocolos de gran valor, la verificación formal puede complementar las auditorías manuales de seguridad.

Auditorías de seguridad frente a programas de recompensas por errores

Una auditoría de seguridad suele ser una revisión planificada, realizada por auditores seleccionados, con un alcance y un calendario definidos.

Un programa de recompensas por errores (bug bounty) es una iniciativa continua que recompensa a investigadores externos por informar de vulnerabilidades de forma responsable.

Las auditorías son útiles antes del lanzamiento porque proporcionan una revisión experta y específica.

Los programas de recompensas son útiles después del lanzamiento porque, con el tiempo, los sistemas pueden enfrentarse a nuevas integraciones, condiciones de mercado y métodos de ataque.

También pueden atraer a investigadores diversos, con distintas habilidades y perspectivas.

Un programa de recompensas no debería sustituir a una auditoría previa a la implementación.

Una auditoría tampoco debería sustituir a la monitorización continua de seguridad tras la implementación.

Los programas sólidos de seguridad cripto suelen utilizar ambos.

Tipos habituales de auditorías de seguridad cripto

Auditorías de contratos inteligentes

Una auditoría de contratos inteligentes revisa el código on-chain que ejecuta la lógica de un protocolo.

Este es el significado más habitual de las auditorías de seguridad en el sector cripto.

Los auditores revisan contratos de tokens, préstamos, staking, bóvedas, gobernanza, pools de liquidez, NFT y bridges.

La revisión busca tanto errores técnicos como fallos en la lógica empresarial.

Auditorías de la arquitectura del protocolo

Una auditoría de arquitectura revisa cómo interactúan los distintos contratos, servicios, participantes y sistemas off-chain.

Es importante porque un protocolo puede ser inseguro aunque cada contrato individual parezca razonable.

Por ejemplo, se puede confiar demasiado en un oráculo, una clave de administración puede tener demasiado poder o una regla de liquidación puede fallar en condiciones extremas de mercado.

Las auditorías de arquitectura ayudan a detectar riesgos a nivel de sistema.

Auditorías de seguridad de bridges

Una auditoría de bridges revisa la verificación de mensajes cross-chain, los conjuntos de validadores, los relayers, los umbrales de firma, la custodia de activos, la lógica de acuñación y los mecanismos de recuperación ante fallos.

Los bridges son de alto riesgo porque suelen controlar activos en más de una cadena.

Un error en un bridge puede afectar tanto a la cadena de origen como a la de destino.

Las auditorías de bridges deberían incluir revisión de código, análisis de la confianza en los validadores, controles operativos y planificación de la respuesta ante emergencias.

Auditorías de seguridad de carteras

Una auditoría de carteras revisa la gestión de claves privadas, la protección de frases de recuperación, la firma de transacciones, la visualización de direcciones, los procesos de recuperación, la lógica de abstracción de cuentas y la seguridad de la interfaz de usuario.

La seguridad de las carteras es fundamental porque los usuarios dependen de ellas para entender qué están firmando.

Una cartera puede contar con una criptografía sólida y, aun así, exponer a los usuarios al phishing si las solicitudes de transacción no son claras.

Las auditorías de carteras deberían incluir revisiones de seguridad tanto técnicas como de experiencia de usuario.

Auditorías de infraestructura

Una auditoría de infraestructura revisa nodos, endpoints RPC, indexadores, servicios de backend, procesos de implementación, controles de acceso, sistemas en la nube, monitorización y procedimientos de respuesta a incidentes.

Los usuarios de criptomonedas suelen centrarse en los contratos inteligentes, pero los fallos de infraestructura también pueden causar grandes pérdidas o interrupciones del servicio.

Un protocolo puede depender de keepers off-chain, fuentes de precios, validadores, secuenciadores, relayers o bots.

Estos sistemas deberían revisarse como parte del modelo de seguridad general.

Cómo funciona una auditoría de seguridad de contratos inteligentes

Una auditoría de contratos inteligentes suele comenzar definiendo el alcance.

El equipo y los auditores acuerdan qué contratos, ramas, commits, documentación, pruebas, scripts y planes de implementación se incluyen.

A continuación, los auditores estudian el comportamiento previsto del proyecto y su modelo de amenazas.

Revisan el código manualmente y ejecutan herramientas de análisis automatizado.

Pueden escribir exploits de prueba de concepto para confirmar si una vulnerabilidad es real.

También pueden probar casos extremos mediante pruebas unitarias, fuzzing, pruebas de invariantes o simulaciones.

Al finalizar la revisión, entregan los hallazgos, con niveles de gravedad y recomendaciones.

El equipo del proyecto corrige los problemas y los auditores pueden realizar una revisión de las correcciones para confirmar que funcionan.

¿Qué debería incluir el alcance de una auditoría?

El alcance debería incluir todo el código que pueda afectar a los fondos de los usuarios, los permisos, la contabilidad, las actualizaciones, la gobernanza o las integraciones externas.

Debería incluir los contratos inteligentes previstos para la implementación.

Debería incluir los scripts de actualización e implementación, ya que un contrato seguro puede volverse inseguro si se implementa incorrectamente.

También debería incluir archivos de configuración importantes, asignaciones de roles, ajustes de control de acceso y parámetros de inicialización.

Debería abarcar integraciones de oráculos, adaptadores de bridges, lógica de keepers e hipótesis sobre dependencias externas.

También debería incluir documentación que explique el comportamiento previsto y las hipótesis de confianza conocidas.

Un alcance limitado puede reducir el coste de la auditoría, pero también puede pasar por alto riesgos a nivel de sistema.

Quienes lean un informe de auditoría deberían comprobar siempre qué se incluyó y qué se excluyó.

Vulnerabilidades habituales detectadas en auditorías de seguridad

Una vulnerabilidad habitual es la reentrada: una llamada externa permite una ejecución repetida e inesperada antes de que finalicen las actualizaciones del estado.

Otra vulnerabilidad habitual es un control de acceso defectuoso que permite a una dirección no autorizada llamar a funciones privilegiadas.

Otro problema frecuente es la manipulación de oráculos, cuando los atacantes influyen en los precios utilizados por sistemas de préstamos, trading o garantías.

También son frecuentes las actualizaciones inseguras, en las que los contratos proxy o las claves de administración pueden cambiar la lógica de forma peligrosa.

Otro problema común es la repetición de firmas: una firma válida puede reutilizarse en un contexto no previsto.

También puede haber aleatoriedad deficiente cuando los contratos utilizan fuentes predecibles para juegos, loterías o asignaciones de NFT.

El Top 10 de contratos inteligentes de OWASP ofrece una lista actualizada de las principales categorías de riesgo de contratos inteligentes para desarrolladores y equipos de seguridad.

Los auditores utilizan listas como esta como punto de partida, pero las auditorías rigurosas también deben buscar fallos específicos de la lógica del proyecto.

Niveles de gravedad en los informes de auditoría

Los informes de auditoría suelen clasificar los hallazgos según su gravedad.

Los hallazgos críticos pueden permitir el robo directo, la pérdida permanente de fondos, la acuñación no autorizada o la toma de control total del protocolo.

Los hallazgos graves pueden provocar pérdidas importantes, abuso de privilegios, errores contables o una denegación de servicio considerable.

Los hallazgos de gravedad media pueden generar riesgos significativos en determinadas condiciones o al combinarse con otros problemas.

Los hallazgos de gravedad baja pueden incluir debilidades de seguridad menores, casos extremos u oportunidades para reforzar el sistema.

Los hallazgos informativos pueden incluir sugerencias sobre la calidad del código, mejoras en el uso de gas, carencias de documentación o recomendaciones de buenas prácticas.

La gravedad depende en parte de aspectos técnicos y en parte del contexto.

Un error aparentemente menor en un protocolo puede ser crítico en otro si afecta a la contabilidad básica o a controles privilegiados.

Auditorías de seguridad y control de acceso

El control de acceso es una de las partes más importantes de una auditoría de seguridad cripto.

Los auditores comprueban quién puede pausar un contrato, actualizar la lógica, modificar las comisiones, cambiar los oráculos, acuñar tokens, retirar fondos, incluir usuarios en listas de permitidos o modificar los parámetros del protocolo.

También comprueban si los roles privilegiados están asignados a multisig seguras, timelocks, contratos de gobernanza o carteras inseguras controladas por una sola clave.

Un mal control de acceso puede convertir un protocolo que parece descentralizado en un sistema controlado por una sola clave comprometida.

Los auditores deberían identificar claramente los roles privilegiados en el informe.

Los usuarios deberían leer los informes de auditoría para entender quién puede modificar el sistema después del lanzamiento.

Incluso los contratos auditados pueden ser arriesgados si los administradores conservan amplias facultades sin controles transparentes.

Un control de acceso sólido debería seguir el principio de privilegio mínimo.

Auditorías de seguridad y contratos actualizables

Los contratos actualizables permiten modificar la lógica del protocolo después de su implementación.

Esto puede ayudar a los equipos a corregir errores y mejorar las funciones.

También puede generar importantes riesgos de confianza y gobernanza.

Una auditoría debería revisar el patrón proxy, la distribución del almacenamiento, las funciones de inicialización, los permisos de actualización, los timelocks y los controles de emergencia.

Un error en la distribución del almacenamiento puede corromper los saldos o los permisos durante una actualización.

Una función de inicialización desprotegida puede permitir que un atacante tome el control de un contrato.

Un rol de actualización sin restricciones puede sustituir código seguro por código malicioso.

Los usuarios deberían entender si un protocolo auditado puede seguir actualizándose después por decisión de los administradores o de la gobernanza.

Auditorías de seguridad y oráculos

Los oráculos introducen en los contratos inteligentes datos externos, como precios, tipos, reservas o aleatoriedad.

Muchos protocolos DeFi dependen de oráculos para las liquidaciones, los swaps, los límites de préstamo, la valoración de bóvedas y la liquidación de operaciones.

Una auditoría debería comprobar si los datos del oráculo pueden manipularse, retrasarse, quedar desactualizados o configurarse incorrectamente.

También debería revisar la lógica alternativa, la actualización de los datos, la gestión de decimales, los interruptores de emergencia y los riesgos específicos de cada activo.

El riesgo de los oráculos no es solo un problema de código.

También es un problema económico y de estructura de mercado.

Una fuente de precios puede ser técnicamente correcta y, aun así, resultar insegura si el mercado subyacente tiene poca liquidez o es fácil de manipular.

Las auditorías sólidas revisan tanto la integración del oráculo como las hipótesis en las que se basan los datos.

Auditorías de seguridad y ataques económicos

Los protocolos cripto pueden fallar aunque el código no contenga errores de programación evidentes.

Los ataques económicos explotan incentivos, liquidez, gobernanza, tiempos de los oráculos, apalancamiento o mecanismos de mercado.

Un protocolo de préstamos puede fallar si el valor de las garantías puede inflarse temporalmente.

Un pool de liquidez puede vaciarse si se manipulan las fórmulas de precios.

Un sistema de gobernanza puede quedar bajo control ajeno si el poder de voto se puede tomar prestado o concentrar rápidamente.

Un bridge puede fallar si los incentivos de los validadores son débiles o la gestión de claves es deficiente.

Las auditorías deberían tener en cuenta el comportamiento económico, no solo la sintaxis del código.

Por eso, las auditorías DeFi suelen requerir conocimientos de ingeniería y análisis de riesgos financieros.

Auditorías de seguridad y herramientas automatizadas

Las herramientas automatizadas pueden ayudar a los auditores a detectar rápidamente patrones de vulnerabilidad conocidos.

Entre ellas puede haber analizadores estáticos, herramientas de fuzzing, ejecución simbólica, linters, analizadores de dependencias y marcos para probar invariantes.

Estas herramientas son útiles, pero no sustituyen la revisión manual de expertos.

Un artículo de investigación reciente sobre analizadores de seguridad de contratos inteligentes detectó grandes diferencias en la precisión de las herramientas y señaló problemas como falsos positivos, falsos negativos, explicaciones vagas y tiempos de ejecución prolongados.

Esto significa que los resultados deben revisarlos personas que entiendan el contexto del protocolo.

Las herramientas automatizadas son más útiles para ampliar la cobertura, repetir tareas y detectar patrones conocidos.

Los auditores manuales son más eficaces a la hora de analizar la lógica empresarial, el razonamiento económico, la arquitectura y las vías de ataque creativas.

Una auditoría rigurosa utiliza las herramientas como asistentes, no como jueces definitivos.

Auditorías de seguridad y pruebas

Las pruebas son la base de un buen proceso de auditoría.

Antes de una auditoría externa, el equipo debería contar, cuando corresponda, con pruebas unitarias, de integración, de fuzzing y de invariantes.

Las pruebas unitarias comprueban funciones individuales.

Las pruebas de integración comprueban cómo funcionan los componentes en conjunto.

Las pruebas de fuzzing utilizan numerosas entradas aleatorias o semialeatorias para descubrir fallos inesperados.

Las pruebas de invariantes comprueban si las reglas importantes se mantienen siempre.

Por ejemplo, un protocolo de préstamos puede exigir que la contabilidad de la deuda total y de las garantías se mantenga siempre coherente.

La auditoría es más eficaz cuando los auditores pueden revisar y ampliar un conjunto de pruebas existente, en vez de empezar desde cero.

Auditorías de seguridad y estándares

Los estándares de seguridad ayudan a equipos y auditores a aplicar criterios coherentes.

El Estándar de verificación de seguridad de contratos inteligentes de OWASP establece requisitos y pruebas de seguridad para contratos inteligentes, dApps y sistemas blockchain basados en EVM.

La especificación de niveles de seguridad EthTrust de la EEA define los requisitos para los niveles de certificación de seguridad de contratos inteligentes.

Los estándares no sustituyen la revisión de expertos, pero permiten que las auditorías sean más coherentes y fáciles de comparar.

También ayudan a los equipos de desarrollo a prepararse antes de la llegada de los auditores.

Un protocolo que sigue un estándar reconocido aún puede tener errores, pero parte de una estructura más adecuada para la revisión de seguridad.

Los usuarios deberían preferir informes de auditoría que expliquen la metodología y no se limiten a mostrar un logotipo o un titular.

Una metodología clara facilita la evaluación de la auditoría.

Qué debería incluir un informe de auditoría

Un informe de auditoría útil debería identificar el proyecto, el alcance de la auditoría, el commit del código, las fechas, los auditores, la metodología y las limitaciones.

Debería describir el protocolo a grandes rasgos.

Debería enumerar todos los hallazgos e indicar su gravedad, impacto, probabilidad, archivos afectados, explicación técnica y corrección recomendada.

Debería indicar si cada problema se ha corregido, corregido parcialmente, reconocido o dejado sin resolver.

Debería explicar los riesgos de centralización, las facultades de administración, los controles de actualización y los roles de confianza.

Debería mencionar las principales hipótesis que quedaron fuera del alcance de la auditoría.

Debería ofrecer suficiente detalle para que los desarrolladores puedan actuar y los usuarios entiendan los riesgos principales.

Un certificado impreciso sin detalles técnicos resulta mucho menos útil que un informe claro.

Cómo deberían leer los usuarios un informe de auditoría

Lo primero es comprobar si el informe corresponde a los contratos implementados.

Una auditoría de una versión antigua del código puede no ser aplicable a la implementación actual.

Los usuarios deberían comprobar el hash del commit, las direcciones de los contratos, la fecha de implementación y el historial de actualizaciones.

También deberían leer los hallazgos sin resolver, en lugar de fijarse únicamente en la palabra «auditado».

Un proyecto puede estar auditado y seguir presentando riesgos graves reconocidos.

Los usuarios deberían comprobar si los hallazgos críticos y graves se corrigieron antes del lanzamiento.

También deberían revisar los riesgos de centralización, las claves de administración, las hipótesis sobre oráculos y las dependencias externas.

La forma más prudente de interpretarlo es sencilla: una auditoría demuestra que se ha realizado una revisión, no que el sistema sea seguro.

Auditorías de seguridad antes del lanzamiento de la mainnet

Una auditoría previa al lanzamiento revisa el código antes de que gestione valor real.

Es el mejor momento para encontrar problemas graves, ya que pueden corregirse antes de que los usuarios depositen activos.

Los equipos no deberían esperar hasta el último día antes del lanzamiento para solicitar una auditoría.

Los auditores necesitan tiempo para entender el sistema, comprobar las hipótesis, hacer preguntas y revisar las correcciones.

Una auditoría hecha con prisas puede pasar por alto problemas importantes.

El equipo debería congelar el código antes de iniciar la auditoría.

Si el código cambia constantemente durante la revisión, el alcance de la auditoría se vuelve inestable.

Un proceso limpio de auditoría antes del lanzamiento incluye preparación, congelación del código, revisión, corrección de problemas, nuevas pruebas e implementación cuidadosa.

Auditorías de seguridad después de la implementación

Las auditorías posteriores a la implementación son importantes cuando un protocolo se actualiza, añade módulos, modifica oráculos o la gobernanza, o se integra con nuevos sistemas.

Los protocolos cripto no son estáticos.

Con el tiempo, pueden añadir activos, cadenas, bóvedas, mercados, estrategias o rutas de bridges.

Cada cambio puede generar nuevos riesgos.

Un protocolo que era seguro en su lanzamiento puede volverse arriesgado tras una actualización mal revisada.

Las auditorías posteriores a la implementación ayudan a reducir este riesgo.

Los equipos también deberían monitorizar el comportamiento del protocolo en funcionamiento, ya que algunos riesgos solo aparecen en condiciones reales de mercado.

La seguridad es un proceso continuo, no un evento puntual.

Auditorías de seguridad para protocolos DeFi

Las auditorías de seguridad DeFi deben revisar tanto el código como la lógica financiera.

Un protocolo DeFi puede depender de ratios de garantía, modelos de interés, profundidad de liquidez, fuentes de precios, incentivos de liquidación, cálculo de comisiones y comportamiento de los usuarios.

Los auditores deberían comprobar si los usuarios pueden vaciar pools, eludir controles de deuda, manipular precios, robar recompensas o bloquear fondos.

También deberían revisar el redondeo, las conversiones de decimales, las hipótesis de deslizamiento y la compatibilidad de los tokens.

Las auditorías DeFi deberían tener en cuenta tokens inusuales, como los que cobran comisiones por transferencia, los tokens rebasing y los que incorporan funciones de pausa o listas negras.

También deberían revisar los controles de emergencia y el comportamiento de las retiradas en situaciones de estrés.

Para los usuarios, un protocolo DeFi auditado sigue siendo arriesgado si la liquidez es escasa o la gobernanza está centralizada.

El estado de auditoría debería ser solo una parte del análisis de diligencia debida sobre DeFi.

Auditorías de seguridad para bridges

Las auditorías de bridges están entre los tipos más importantes y difíciles de auditorías de seguridad cripto.

Un bridge puede bloquear activos en una cadena y acuñarlos o liberarlos en otra.

Esto genera riesgos en los contratos inteligentes, la verificación de mensajes, los relayers, los validadores, las firmas, la custodia y las hipótesis sobre finalidad.

Los auditores deberían revisar cómo demuestra el bridge que se ha producido un evento en otra cadena.

También deberían examinar cómo se protegen las claves de los validadores y cuántas firmas se requieren.

Las auditorías de bridges deberían probar ataques de repetición, aceptación de mensajes no válidos, riesgos de reorganización de la cadena, límites de retirada y mecanismos de cierre de emergencia.

Los usuarios deberían tener cuidado con los bridges aunque estén auditados, ya que los sistemas cross-chain dependen de más hipótesis que las transferencias sencillas de tokens.

Una auditoría de bridge debería explicar esas hipótesis con claridad.

Auditorías de seguridad para NFT y videojuegos

Las auditorías de NFT y videojuegos revisan la lógica de acuñación, el control de metadatos, la aleatoriedad, las regalías, las restricciones de transferencia, las aprobaciones de marketplaces y las reglas de los activos del juego.

La aleatoriedad es especialmente importante cuando los usuarios pagan por acuñaciones sorpresa, cajas de botín o atributos aleatorios.

Una aleatoriedad deficiente puede permitir que personas internas, mineros, validadores o bots predigan o manipulen los resultados.

Los auditores también deberían comprobar si el propietario del proyecto puede modificar los metadatos de forma engañosa.

Los proyectos de videojuegos deberían revisar la acuñación y quema de activos, las recompensas, la lógica del inventario y el movimiento de activos entre cadenas.

Los usuarios de NFT no deberían suponer que un proyecto es seguro solo porque se haya auditado el contrato de acuñación.

También importan el sitio web, las solicitudes de la cartera, las aprobaciones de marketplaces y los controles de administración.

Cuando sea posible, una auditoría de NFT debería cubrir todo el recorrido del usuario.

Auditorías de seguridad para carteras

Las auditorías de carteras son fundamentales porque las carteras son la principal interfaz entre los usuarios y las blockchains.

Una auditoría de cartera debería revisar la generación de frases de recuperación, el almacenamiento de claves privadas, los procesos de firma, la visualización de direcciones, los procedimientos de copia de seguridad, la simulación de transacciones y las protecciones contra el phishing.

También debería revisar los permisos de las extensiones del navegador, el almacenamiento de las aplicaciones móviles, la integración con carteras físicas y la distribución de actualizaciones.

Una cartera puede fallar si firma datos incorrectos, muestra una dirección equivocada u oculta detalles importantes de una transacción.

Las auditorías de carteras deberían incluir la facilidad de uso para que los usuarios entiendan qué están aprobando.

Una firma clara puede reducir errores, pero solo si los detalles de la transacción se muestran correctamente.

La seguridad de las carteras también depende de canales de actualización seguros y de la protección frente a versiones falsas.

Los usuarios deberían descargar carteras únicamente desde fuentes de confianza y guardar las frases de recuperación sin conexión.

Auditorías de seguridad y riesgos de gobernanza

El riesgo de gobernanza aparece cuando los titulares de tokens, delegados, multisig o administradores pueden modificar el comportamiento del protocolo.

Una auditoría debería revisar las reglas de votación, los umbrales de propuestas, el quórum, los timelocks, las facultades de emergencia y la lógica de ejecución.

Debería comprobar si los atacantes pueden tomar prestado poder de voto, aprobar propuestas maliciosas o eludir los plazos de espera.

También debería analizar si un grupo reducido puede actualizar contratos o mover fondos de tesorería.

La gobernanza puede ser una ventaja si es transparente y está bien diseñada.

Puede ser un riesgo si otorga un control amplio a claves mal protegidas o a sistemas de votación con poca participación.

Los usuarios deberían consultar las hipótesis sobre gobernanza en los informes de auditoría.

Un protocolo puede estar auditado técnicamente y seguir estando muy centralizado.

Auditorías de seguridad y seguridad operativa

La seguridad operativa abarca cómo gestiona un equipo las claves, las implementaciones, el acceso, la monitorización y la respuesta ante emergencias.

Un protocolo puede tener código seguro y, aun así, operar de forma insegura.

Por ejemplo, una clave de implementación podría guardarse en un portátil inseguro.

Una multisig podría tener muy pocos firmantes o una distribución deficiente entre ellos.

Una actualización podría ejecutarse sin una lista de comprobación.

Un sistema de alertas podría fallar durante un ataque.

Las auditorías deberían revisar las hipótesis operativas cuando afecten a los fondos de los usuarios.

Una seguridad operativa sólida incluye almacenamiento seguro de claves, separación de funciones, registros, monitorización, protocolos de respuesta a incidentes y análisis posterior de los incidentes.

Auditorías de seguridad y limitaciones

Una auditoría de seguridad no puede detectar todos los errores posibles.

No puede garantizar que un protocolo nunca vaya a sufrir un exploit.

No puede predecir completamente las condiciones futuras del mercado, las decisiones de gobernanza ni los cambios de integración.

No puede proteger a los usuarios que firmen transacciones maliciosas fuera del sistema auditado.

No puede solucionar una documentación deficiente, una implementación precipitada o una mala respuesta ante incidentes si el equipo no actúa a partir de los hallazgos.

Tampoco puede hacer seguras las futuras actualizaciones que no se hayan auditado.

Por eso, los usuarios no deberían tratar la palabra «auditado» como una etiqueta binaria de seguridad.

La pregunta real es qué se auditó, quién lo revisó, qué se encontró, qué se corrigió y qué riesgos siguen presentes.

Señales de alerta en las auditorías de seguridad

Si un proyecto afirma estar auditado, la ausencia de un informe público es una señal de alerta.

Un informe sin alcance, hash del commit ni detalles de los hallazgos es una señal de alerta.

Un informe que incluya hallazgos críticos sin resolver es una señal de advertencia importante.

Un proyecto que modifica el código después de la auditoría sin someterlo a una nueva revisión genera riesgos adicionales.

Los proyectos que ocultan las facultades de administración o los permisos de actualización deben tratarse con cautela.

Un proyecto que afirma que una auditoría garantiza la seguridad está haciendo una afirmación engañosa.

Un proyecto sin conjunto de pruebas, monitorización ni proceso de emergencia puede seguir siendo arriesgado después de una auditoría.

Los usuarios deberían desconfiar cuando la auditoría se utiliza únicamente como herramienta de marketing.

Buenas prácticas antes de solicitar una auditoría

Los equipos deberían redactar documentación clara antes de solicitar una auditoría.

Deberían congelar el código o definir el commit exacto que se revisará.

Deberían preparar diagramas de arquitectura, modelos de amenazas, planes de implementación e invariantes previstas.

Deberían incluir un conjunto completo de pruebas y explicar los problemas conocidos.

Deberían evitar añadir funciones importantes durante la auditoría.

Deberían conceder a los auditores tiempo suficiente para revisar el sistema con cuidado.

Deberían responder rápidamente a las preguntas y corregir los hallazgos de forma meditada.

Un equipo preparado obtiene más valor de una auditoría que otro que trata a los auditores como una lista de comprobación de última hora.

Buenas prácticas después de una auditoría

Los equipos deberían corregir los hallazgos graves antes del lanzamiento.

Deberían pedir a los auditores que revisen las correcciones importantes.

Deberían publicar el informe definitivo cuando sea seguro y apropiado.

Deberían documentar los riesgos reconocidos que no se hayan corregido.

Deberían verificar el bytecode implementado y las direcciones de los contratos.

Deberían monitorizar el protocolo después del lanzamiento.

Si el protocolo controla un valor significativo, deberían poner en marcha un programa de recompensas por errores o un proceso de divulgación responsable.

Deberían programar nuevas auditorías para las actualizaciones importantes.

Cómo pueden evaluar los usuarios un proyecto auditado

Lo primero es confirmar que el informe de auditoría es auténtico y público.

Deberían comprobar si el informe abarca los contratos implementados actualmente.

Deberían buscar problemas críticos o graves sin resolver.

También deberían comprobar si los sistemas complejos o de gran valor cuentan con varias auditorías.

Deberían revisar los controles de administración, la capacidad de actualización, el diseño de los oráculos, la custodia y las dependencias de bridges.

Deberían comprobar si el protocolo dispone de un programa de recompensas por errores, monitorización y un plan de pausa de emergencia.

Deberían tener en cuenta el valor total bloqueado, ya que un valor más elevado puede atraer a atacantes más sofisticados.

Una auditoría debería aumentar la confianza, pero no eliminar la cautela.

Auditorías de seguridad y seguros

Algunos usuarios de criptomonedas buscan seguros o coberturas después de ver una auditoría.

Una auditoría puede ayudar a las aseguradoras o a quienes evalúan el riesgo a entender un protocolo, pero no proporciona automáticamente cobertura de seguro.

Las condiciones de cobertura pueden excluir determinados exploits, fallos de gobernanza, ataques a oráculos, fallos de bridges o errores de los usuarios.

Los usuarios deberían leer atentamente las condiciones del seguro antes de confiar en él.

Los protocolos no deberían insinuar que una auditoría protege económicamente a los usuarios, a menos que exista un acuerdo de cobertura real.

Los seguros, las auditorías, los programas de recompensas y la monitorización son herramientas distintas de gestión del riesgo.

Cada una tiene limitaciones diferentes.

Una seguridad sólida requiere varias capas.

Auditorías de seguridad y expectativas regulatorias

La regulación cripto presta cada vez más atención a los controles de seguridad, la custodia, la divulgación, la resiliencia operativa y la gestión del riesgo.

Una auditoría de seguridad puede ayudar a demostrar que un proyecto se ha tomado en serio los riesgos técnicos.

Sin embargo, una auditoría de contratos inteligentes no equivale al cumplimiento jurídico.

Un token puede estar auditado y aun así plantear cuestiones relacionadas con valores negociables, protección del consumidor, sanciones, impuestos o custodia.

Los proyectos que gestionan fondos de usuarios deberían considerar una revisión jurídica además de una revisión técnica.

La seguridad y el cumplimiento son disciplinas distintas, aunque a menudo se solapan en los productos cripto.

Por ejemplo, una plataforma de activos tokenizados puede necesitar auditorías de contratos inteligentes y controles jurídicos sobre los registros de propiedad.

Los usuarios no deberían confundir la seguridad técnica con la aprobación regulatoria.

Ideas equivocadas habituales sobre las auditorías de seguridad

Una idea equivocada habitual es que «auditado» significa «seguro».

«Auditado» significa que se ha revisado dentro de un alcance definido, no que vaya a ser seguro para siempre.

Otra idea equivocada es que una auditoría basta para todas las versiones futuras.

El código nuevo, los activos nuevos, las cadenas nuevas y las nuevas integraciones pueden generar riesgos nuevos.

Otra idea equivocada es que las herramientas automatizadas pueden sustituir a los auditores humanos.

Las herramientas ayudan, pero a menudo no detectan fallos de lógica específicos del contexto.

Otra idea equivocada es que solo necesitan auditorías de seguridad los contratos inteligentes.

Las carteras, los bridges, los frontends, los backends, los sistemas de gobernanza y los procesos operativos también requieren una revisión de seguridad.

Preguntas frecuentes

¿Qué es una auditoría de seguridad en el sector cripto?

Es una revisión estructurada de contratos inteligentes, protocolos, carteras o infraestructuras para identificar vulnerabilidades antes de que los atacantes puedan explotarlas.

¿Qué es una auditoría de contratos inteligentes?

Es una revisión de seguridad del código on-chain que busca errores, lógica insegura, problemas de control de acceso, fallos de oráculos y otras vías de explotación.

¿Una auditoría significa que un proyecto cripto es seguro?

No. Una auditoría aumenta la confianza, pero no garantiza que un proyecto sea completamente seguro o esté protegido frente a futuros exploits.

¿Qué debería incluir un informe de auditoría?

Debería incluir el alcance, el hash del commit, la metodología, los hallazgos, los niveles de gravedad, las recomendaciones, el estado de las correcciones, las limitaciones y los riesgos restantes.

¿Por qué necesitan auditorías los contratos inteligentes?

Las necesitan porque pueden controlar directamente los fondos de los usuarios y puede ser difícil modificarlos después de su implementación.

¿Cuál es la diferencia entre una auditoría y un programa de recompensas por errores?

Una auditoría es una revisión específica realizada por auditores seleccionados, mientras que un programa de recompensas ofrece incentivos continuos a investigadores externos que informen de vulnerabilidades.

¿Pueden las herramientas automatizadas sustituir a los auditores de seguridad?

No. Las herramientas automatizadas son útiles para detectar patrones conocidos, pero hacen falta auditores humanos para encontrar fallos lógicos, ataques económicos y problemas específicos del protocolo.

¿Cuáles son los hallazgos habituales en una auditoría?

Entre ellos se encuentran la reentrada, los fallos de control de acceso, la manipulación de oráculos, las actualizaciones inseguras, la repetición de firmas, la aleatoriedad deficiente y los errores contables.

¿Con qué frecuencia deberían auditarse los proyectos cripto?

Deberían auditarse antes de los lanzamientos importantes y de nuevo cuando realicen actualizaciones relevantes, añadan módulos, integren nuevos activos o modifiquen hipótesis fundamentales.

¿Qué significa el alcance de una auditoría?

Se refiere al código, los contratos, los sistemas, la documentación y las hipótesis concretos que se incluyeron en la revisión.

¿Por qué es importante el hash de un commit en una auditoría?

El hash permite verificar qué versión exacta del código revisaron los auditores.

¿Todavía pueden hackearse los contratos auditados?

Sí. Las auditorías pueden pasar por alto errores, el código puede cambiar después, las hipótesis pueden fallar o los atacantes pueden explotar áreas fuera del alcance de la auditoría.

¿Deberían confiar los usuarios en un proyecto solo porque está auditado?

No. También deberían revisar los hallazgos sin resolver, las facultades de administración, la capacidad de actualización, los riesgos de los oráculos y los bridges, la liquidez, los programas de recompensas y la seguridad operativa del proyecto.

Conclusión

Las auditorías de seguridad son una de las herramientas más importantes para reducir riesgos en el sector de las criptomonedas.

Ayudan a identificar errores en contratos inteligentes, fallos de diseño de protocolos, permisos inseguros, vías de ataque económico y debilidades operativas antes de que los atacantes puedan explotarlos.

Una buena auditoría revisa no solo el código, sino también las hipótesis, la arquitectura, el control de acceso, la capacidad de actualización, los oráculos, los scripts de implementación y los riesgos que afectan a los usuarios.

Sin embargo, las auditorías de seguridad no ofrecen garantías.

Están limitadas a un periodo y un alcance, y dependen de la calidad de los auditores, la documentación, el código, las pruebas y el proceso de corrección.

Los mejores proyectos cripto consideran las auditorías una parte de un ciclo integral de seguridad que incluye diseño seguro, pruebas, métodos formales, programas de recompensas, monitorización, respuesta a incidentes y actualizaciones cuidadosas.

Los usuarios deberían tratar los informes de auditoría como pruebas útiles, no como eslóganes de marketing.

La regla práctica es sencilla: un proyecto auditado puede ser más seguro que uno sin auditar, pero la verdadera pregunta es qué se auditó, qué se encontró, qué se corrigió y qué riesgos siguen presentes.