samczsun: La seguridad de los protocolos cripto depende fundamentalmente de auditorías proactivas y recurrentes

El programa de recompensas por vulnerabilidades es una medida pasiva, mientras que la protección de la seguridad requiere un enfoque proactivo.

Escrito por: samczsun, fundador de Security Alliance y ex socio de investigación en Paradigm

Actualmente, la industria ha llegado a un consenso: la protección de la seguridad en criptomonedas debe seguir tres pasos clave: escribir casos de prueba en la etapa de desarrollo para detectar errores básicos; realizar auditorías y competencias exhaustivas antes del despliegue; y establecer programas de recompensas por vulnerabilidades para premiar a los investigadores que revelen fallos de manera responsable y así prevenir ataques. La difusión de estas mejores prácticas ha reducido significativamente la cantidad de vulnerabilidades on-chain, obligando a los atacantes a enfocar sus objetivos en robos de claves privadas, intrusiones en infraestructuras y otras vulnerabilidades off-chain.

Sin embargo, incluso los protocolos que han sido auditados exhaustivamente y ofrecen generosas recompensas por vulnerabilidades siguen siendo ocasionalmente víctimas de ataques de hackers. Estos incidentes no solo afectan al protocolo involucrado, sino que también sacuden los cimientos de confianza de todo el ecosistema. Los recientes ataques a Yearn y Balancer V2, así como los incidentes de seguridad de Abracadabra y 1inch a principios de año, demuestran que incluso los protocolos más probados no son absolutamente seguros. ¿Podría la industria cripto haber evitado estos ataques? ¿O es este simplemente el precio inevitable de las finanzas descentralizadas?

Los comentaristas suelen decir que aumentar las recompensas por vulnerabilidades podría haber protegido estos protocolos. Pero incluso dejando de lado la realidad económica, las recompensas por vulnerabilidades son, en esencia, una medida de seguridad pasiva que deja el destino del protocolo en manos de hackers white hat, mientras que la auditoría es una acción proactiva de autoprotección por parte del protocolo. Aumentar las recompensas no puede detener los ataques, ya que esto equivale a duplicar la apuesta, confiando en que los hackers white hat encontrarán las vulnerabilidades antes que los black hat. Si un protocolo realmente quiere protegerse, debe llevar a cabo auditorías adicionales de manera proactiva.

Fondos de tesorería y valor total bloqueado (TVL)

A veces, los hackers aceptan devolver la mayor parte de los fondos robados y quedarse solo con una pequeña parte (generalmente el 10%) como recompensa. Desafortunadamente, la industria llama a esta parte "recompensa white hat", lo que lleva a preguntarse: ¿por qué el protocolo no ofrece directamente la misma cantidad a través de un programa de recompensas, evitando así la molestia de negociar? Pero este pensamiento confunde los fondos que el atacante puede robar con los fondos que el protocolo puede disponer legalmente.

Aunque superficialmente parece que el protocolo puede usar ambos fondos para protección de seguridad, en realidad solo tiene control legal sobre los fondos de su tesorería, y no sobre los fondos depositados por los usuarios. Es muy poco probable que los usuarios otorguen este tipo de permiso de antemano; solo en momentos de crisis (por ejemplo, cuando los depositantes deben elegir entre perder el 10% o el 100% de sus fondos) permitirán que el protocolo use los depósitos para negociar. En otras palabras, el riesgo aumenta junto con el TVL, pero el presupuesto de seguridad no puede crecer al mismo ritmo.

Eficiencia de capital

Incluso si el protocolo tiene fondos suficientes (por ejemplo, una gran tesorería, alta rentabilidad, o ya ha implementado una política de tarifas de seguridad), sigue siendo un desafío asignar estos fondos de manera efectiva para la protección de seguridad. Comparado con invertir en auditorías adicionales, aumentar las recompensas por vulnerabilidades es, en el mejor de los casos, una medida de baja eficiencia de capital y, en el peor, puede causar un desalineamiento de incentivos entre el protocolo y los investigadores.

Si las recompensas por vulnerabilidades están vinculadas al TVL, cuando los investigadores sospechan que el TVL del protocolo aumentará y la probabilidad de que se repita la misma vulnerabilidad es baja, claramente tendrán más incentivos para ocultar vulnerabilidades críticas. Esto finalmente pone a los investigadores en conflicto directo con el protocolo y perjudica los intereses de los usuarios. Simplemente aumentar las recompensas por vulnerabilidades críticas tampoco logra el efecto deseado: el grupo de investigadores freelance es grande, pero muy pocos dedican la mayor parte de su tiempo a recompensas y tienen las habilidades necesarias para encontrar fallos en protocolos complejos. Estos investigadores de élite concentran su tiempo en los programas de recompensas con mayor probabilidad de retorno de inversión. Para los protocolos grandes y probados, que siempre se asume están bajo la atenta mirada de hackers y otros investigadores, la probabilidad de encontrar vulnerabilidades se considera mínima, por lo que, sin importar cuán alta sea la recompensa, no es suficiente para atraer su atención.

Mientras tanto, desde la perspectiva del protocolo, las recompensas por vulnerabilidades son fondos reservados para pagar por una sola vulnerabilidad crítica. A menos que el protocolo esté dispuesto a apostar que nunca aparecerá una vulnerabilidad crítica y a ocultar su situación de liquidez a los investigadores, estos fondos no pueden ser utilizados para otros fines. En lugar de esperar pasivamente a que los investigadores encuentren una vulnerabilidad crítica, es mejor usar la misma cantidad de fondos para realizar múltiples auditorías adicionales a lo largo de los años. Cada revisión garantiza la atención de los mejores investigadores y no se limita artificialmente a encontrar una sola vulnerabilidad, además de alinear los intereses de los investigadores y el protocolo: si el protocolo es explotado, ambas partes sufrirán daños reputacionales.

Precedentes existentes

En las industrias de software y finanzas, las auditorías anuales son una práctica madura y comprobada, y la mejor manera de determinar si una empresa puede hacer frente a un entorno de amenazas en constante evolución. El informe SOC 2 Tipo II es utilizado por clientes B2B para evaluar si los proveedores mantienen controles de seguridad adecuados; la certificación PCI DSS indica que una empresa ha tomado medidas apropiadas para proteger información sensible de pagos; el gobierno de Estados Unidos exige que las partes que manejan información gubernamental obtengan la certificación FedRAMP para mantener altos estándares de seguridad.

Si bien los contratos inteligentes son inmutables, el entorno en el que operan no lo es. Las configuraciones pueden cambiar con el tiempo, las dependencias pueden actualizarse, y patrones de código previamente considerados seguros pueden resultar riesgosos. Una auditoría de protocolo es una evaluación de la seguridad en el momento de la auditoría, no una garantía prospectiva de la seguridad futura del protocolo. La única manera de actualizar esta evaluación es realizar una nueva auditoría.

En 2026, la industria cripto debería adoptar las auditorías anuales como el cuarto paso en la protección de la seguridad de los protocolos. Los protocolos existentes con alto TVL deberían realizar auditorías adicionales sobre sus despliegues; las firmas de auditoría deberían ofrecer servicios especializados enfocados en evaluar el estado general de los despliegues; y todo el ecosistema debería cambiar colectivamente su percepción sobre los informes de auditoría: son solo evaluaciones de seguridad en un momento específico, pueden caducar y no son garantías de seguridad permanentes.