Divulgación de vulnerabilidades

¿Qué es la divulgación de vulnerabilidades?

La divulgación de vulnerabilidades es el proceso de informar, validar, corregir y comunicar públicamente una debilidad de seguridad en software, contratos inteligentes, wallets, protocolos, infraestructura o aplicaciones Web3.

En cripto, la divulgación de vulnerabilidades es especialmente importante porque un solo error puede poner en riesgo los fondos de los usuarios, las tesorerías de los protocolos, los bridges, los validadores, los contratos de gobernanza, las wallets, los NFT o las posiciones DeFi.

Las Directrices federales de divulgación de vulnerabilidades del NIST describen la divulgación de vulnerabilidades como un marco para informar, evaluar y gestionar dichas divulgaciones.

El Programa de divulgación coordinada de vulnerabilidades de CISA describe la divulgación coordinada de vulnerabilidades como parte de la protección de infraestructuras críticas y la mejora de la ciberseguridad.

En términos sencillos, la divulgación de vulnerabilidades consiste en informar a las personas adecuadas sobre un fallo de seguridad antes de que los atacantes puedan explotarlo o de que los usuarios sufran daños evitables.

Un buen proceso de divulgación proporciona a los investigadores de seguridad una vía segura para informar.

Da a los equipos de proyecto tiempo para confirmar el problema, preparar una corrección, proteger a los usuarios y comunicarse con claridad.

También proporciona al público información suficiente para comprender el riesgo una vez resuelto el problema.

Por qué es importante la divulgación de vulnerabilidades en cripto

La divulgación de vulnerabilidades es importante en cripto porque los sistemas blockchain suelen gestionar valor financiero real directamente mediante código.

Un error en una aplicación web convencional puede exponer datos o interrumpir el servicio.

Un error en un contrato inteligente puede permitir el robo instantáneo de activos, la acuñación infinita, la manipulación de oráculos, la toma de control de la gobernanza, el vaciado de un bridge, el abuso de liquidaciones o el bloqueo permanente de fondos.

La base de datos de hackeos de DeFiLlama registra miles de millones de dólares en pérdidas por hackeos DeFi, bridges, fallos en la lógica de protocolos y otros exploits cripto.

Esto demuestra que la divulgación de vulnerabilidades en cripto no es solo una cortesía técnica.

Es un proceso de seguridad financiera.

Cuando un whitehat informa responsablemente de un error, un protocolo puede resolverlo antes de que los atacantes lo descubran.

Cuando un protocolo ignora los informes o no cuenta con un canal de divulgación, es posible que los investigadores no sepan dónde informar de forma segura.

Cuando la divulgación se produce demasiado pronto, los atacantes pueden explotar la debilidad antes de que los usuarios estén protegidos.

Cuando se produce demasiado tarde, los usuarios pueden seguir interactuando con código arriesgado sin conocer el peligro.

El objetivo es reducir los daños manteniendo la transparencia.

Divulgación de vulnerabilidades frente a divulgación coordinada de vulnerabilidades

La divulgación de vulnerabilidades es el acto general de informar y comunicar un fallo de seguridad.

La divulgación coordinada de vulnerabilidades, a menudo abreviada como CVD, es un proceso estructurado en el que el investigador, el proveedor, el equipo del proyecto, las partes afectadas y, en ocasiones, un coordinador colaboran antes de la divulgación pública.

La guía de CERT sobre divulgación coordinada de vulnerabilidades explica la CVD como un proceso en el que intervienen descubridores, informantes, proveedores y coordinadores.

En Web3, la divulgación coordinada puede involucrar a un investigador de seguridad, el equipo principal del protocolo, firmantes de multisig, delegados de una DAO, auditores, desarrolladores de wallets, operadores de bridges, proveedores de infraestructura o una plataforma de bug bounty.

La coordinación es importante porque los sistemas cripto suelen ser componibles.

Una vulnerabilidad en un protocolo puede afectar a otros protocolos que lo integran.

Un error en una biblioteca de wallet puede afectar a muchas aplicaciones.

Una vulnerabilidad en un bridge puede afectar a activos en múltiples cadenas.

Un proceso de divulgación debe identificar quién debe conocer la información, cuándo debe conocerla y cómo puede compartirse sin aumentar el riesgo de ataque.

Divulgación de vulnerabilidades frente a bug bounty

La divulgación de vulnerabilidades y los bug bounties están relacionados, pero no son lo mismo.

La divulgación de vulnerabilidades es el proceso de informar y gestionar una debilidad de seguridad.

Un bug bounty es un programa de recompensas que paga a los investigadores por informes de vulnerabilidades válidos.

Un proyecto puede contar con una política de divulgación de vulnerabilidades sin ofrecer recompensas.

También puede tener un programa de bug bounty con un alcance estricto, normas de gravedad, rangos de pago, requisitos de información y restricciones de divulgación.

El programa de bug bounty de Ethereum Foundation muestra cómo un ecosistema de protocolo importante define canales de información, alcance y expectativas de investigación de seguridad.

Los bug bounties pueden animar a los investigadores a informar de problemas en lugar de venderlos de forma privada o explotarlos.

Sin embargo, una recompensa no hace que un proyecto sea seguro automáticamente.

El proyecto sigue necesitando triaje, respuesta de ingeniería, implementación de parches, comunicación con los usuarios y planificación de incidentes.

Un bug bounty es una capa de incentivos, mientras que la divulgación de vulnerabilidades es el flujo de trabajo de seguridad completo.

Divulgación responsable frente a divulgación completa

La divulgación responsable suele consistir en informar de una vulnerabilidad de forma privada al equipo afectado y darle tiempo para resolverla antes de publicar los detalles.

La divulgación completa consiste en compartir públicamente los detalles de una vulnerabilidad, a veces de inmediato y otras tras una fecha límite.

En cripto, la divulgación completa inmediata puede ser extremadamente peligrosa si el error afecta a contratos inteligentes activos con fondos de usuarios.

Los atacantes pueden copiar el informe y explotar el protocolo antes de que se implemente una corrección.

Sin embargo, una divulgación privada indefinida también puede ser perjudicial, ya que los usuarios pueden seguir expuestos mientras un proyecto retrasa su actuación.

Por este motivo, la divulgación coordinada suele utilizar cronogramas, normas de escalado y expectativas de divulgación pública.

El repositorio de divulgaciones públicas de Ethereum indica que Ethereum Foundation tiene como objetivo divulgar públicamente los errores comunicados mediante su programa de bug bounty en 90 días, ajustando el plazo cuando las circunstancias lo requieran.

Un cronograma claro ayuda a equilibrar la protección de los usuarios, la equidad para los investigadores y la transparencia pública.

Política de divulgación de vulnerabilidades

Una política de divulgación de vulnerabilidades indica a los investigadores cómo informar de problemas de seguridad de forma segura.

Debe explicar qué sistemas están dentro del alcance.

Debe explicar qué pruebas están permitidas.

Debe explicar qué pruebas están prohibidas.

Debe enumerar el canal oficial de información.

Debe describir los tiempos de respuesta previstos.

Debe explicar el texto de puerto seguro, si está disponible.

Debe describir cómo se gestionará la divulgación pública.

Debe indicar si se ofrecen recompensas.

Debe informar a los investigadores sobre cómo proteger los datos de los usuarios y evitar daños.

La página de la norma ISO/IEC 29147:2018 establece que la divulgación de vulnerabilidades proporciona requisitos y recomendaciones para que los proveedores divulguen vulnerabilidades en productos y servicios.

En los proyectos cripto, una política de divulgación también debería explicar el alcance de los contratos inteligentes, frontend, oráculos, bridges, wallets, gobernanza y procesos de emergencia de tesorería.

Security.txt y canales de información

Los investigadores de seguridad a menudo tienen dificultades para encontrar el contacto correcto al que informar de una vulnerabilidad.

Por eso existe security.txt.

RFC 9116 define security.txt como un formato legible por máquinas que ayuda a las organizaciones a describir sus prácticas de divulgación de vulnerabilidades.

Un archivo security.txt puede incluir información de contacto, claves de cifrado, enlaces a políticas, enlaces de empleo, reconocimientos y preferencias de divulgación.

Para los proyectos cripto, security.txt puede ayudar a los whitehats a encontrar rápidamente la vía correcta para informar.

Esto es importante porque cada hora puede ser decisiva ante un riesgo de exploit activo.

Un proyecto no debería obligar a los investigadores a buscar en canales sociales aleatorios, enviar mensajes directos a los fundadores o adivinar qué dirección de correo electrónico es auténtica.

Los canales de información claros reducen la confusión y mejoran la velocidad de respuesta.

Un proyecto Web3 con un valor significativo en riesgo debería publicar un contacto de seguridad en la documentación oficial, el pie de página de su sitio web, la política de seguridad del repositorio y el archivo security.txt.

Vulnerabilidades cripto comunes que requieren divulgación

La divulgación de vulnerabilidades en cripto puede abarcar muchos tipos de debilidades.

Los errores de contratos inteligentes pueden incluir reentrancy, fallos de control de acceso, manipulación de oráculos de precios, errores aritméticos, errores de lógica de negocio, llamadas externas no comprobadas y fallos de actualizabilidad.

El Top 10 de contratos inteligentes de OWASP 2026 enumera riesgos importantes para los contratos inteligentes Web3, como vulnerabilidades de control de acceso, vulnerabilidades de lógica de negocio, manipulación de oráculos de precios, ataques de flash loans, llamadas externas no comprobadas, reentrancy, desbordamiento y subdesbordamiento de enteros, y problemas de actualizabilidad mediante proxy.

Las vulnerabilidades de wallets pueden implicar firmas inseguras, exposición de frases de recuperación, fallos de simulación de transacciones, solicitudes maliciosas de dApps o almacenamiento inseguro de claves.

Las vulnerabilidades de bridges pueden implicar la puesta en riesgo de validadores, fallos de verificación de mensajes, ataques de repetición, comprobaciones de finalización insuficientes o debilidades de custodia.

Las vulnerabilidades de frontend pueden incluir secuestro de DNS, inyección maliciosa de JavaScript, direcciones de contratos falsas, dependencias de paquetes comprometidas o cambios en la interfaz destinados a vaciar wallets.

Las vulnerabilidades de infraestructura pueden incluir errores de RPC, errores de indexadores, problemas de clientes de validadores, exposición de API, gestión de claves privadas o configuraciones incorrectas de la nube.

Los buenos programas de divulgación definen cuáles de estos problemas están dentro del alcance y cómo deben comunicarse.

Divulgación de vulnerabilidades de contratos inteligentes

La divulgación de vulnerabilidades de contratos inteligentes es especialmente delicada porque los contratos inteligentes pueden ser públicos, inmutables y estar conectados directamente a fondos.

Un investigador que descubra un error en un contrato inteligente debería evitar explotarlo para obtener beneficio.

Debe evitar mover fondos de usuarios salvo que exista un proceso de puerto seguro o rescate de emergencia claramente autorizado.

Debe recopilar pruebas suficientes para demostrar el problema sin causar daños innecesarios.

El equipo del protocolo debería confirmar la recepción del informe rápidamente.

El equipo debería reproducir el problema en un entorno seguro.

Debería evaluar los contratos y fondos afectados, las integraciones, las vías de actualización y los controles de gobernanza.

Debería decidir si pausar, actualizar, migrar, notificar a los integradores o adoptar medidas de emergencia.

Una vez establecida la protección, el equipo debería publicar un postmortem o aviso claro cuando sea seguro hacerlo.

La divulgación de contratos inteligentes debe ser prudente porque, una vez que los detalles del exploit son públicos, los atacantes pueden actuar rápidamente.

Plataformas de bug bounty en Web3

Las plataformas de bug bounty ayudan a gestionar el envío de vulnerabilidades, el triaje, las recompensas, la clasificación de gravedad, la comunicación con investigadores y el alcance del programa.

La plataforma Immunefi indica que utiliza un amplio conjunto de datos sobre exploits de blockchain, informes de errores y correcciones para respaldar la defensa de seguridad on-chain.

La investigación de Immunefi de 2026 sobre vulnerabilidades cripto críticas informó de que una gran parte de las vulnerabilidades críticas posteriores al lanzamiento en cripto se divulgó a través de su plataforma.

Una plataforma de bug bounty puede ayudar a los proyectos a recibir informes de forma estructurada.

También puede ayudar a los investigadores a entender dónde enviarlos, qué es elegible y cómo se calculan las recompensas.

Sin embargo, una plataforma no elimina la responsabilidad del equipo del proyecto.

El proyecto sigue necesitando ingenieros, responsables de seguridad, firmantes de emergencia, revisión legal y planes de comunicación.

Una bandeja de entrada de recompensas sin capacidad de respuesta puede frustrar a los investigadores y aumentar el riesgo para los usuarios.

Un programa Web3 de recompensas serio debería corresponderse con el valor en riesgo.

Evaluación de gravedad e impacto

La evaluación de gravedad determina el nivel de peligro de una vulnerabilidad.

En cripto, la gravedad debería centrarse en el impacto realista, no solo en la elegancia técnica.

Una vulnerabilidad crítica puede permitir robo directo, pérdida permanente de fondos, acuñación infinita, toma de control de la gobernanza, compromiso de un bridge, slashing de validadores o la paralización del protocolo.

Un problema de alta gravedad puede requerir condiciones especiales, pero seguir amenazando fondos importantes o permisos relevantes.

Un problema de gravedad media puede generar pérdidas limitadas, denegación de servicio, contabilidad incorrecta o escalada de privilegios restringida.

Un problema de baja gravedad puede ser una debilidad menor con impacto práctico limitado.

Una buena clasificación de gravedad debe tener en cuenta los activos en riesgo, la complejidad del exploit, los privilegios necesarios, los usuarios afectados, la componibilidad, la actualizabilidad y si los atacantes pueden explotar el problema on-chain en una sola transacción.

La gravedad también debería considerar si el error ya es conocido, ya ha sido explotado o es visible en código público.

Un programa de divulgación sólido explica cómo se relaciona la gravedad con la prioridad de respuesta y el rango de recompensas.

Cronograma de divulgación

Un cronograma de divulgación define cuándo se confirma la recepción de los informes, cuándo se realiza el triaje, cuándo se esperan las correcciones y cuándo puede producirse la divulgación pública.

La divulgación de software tradicional suele utilizar plazos de 60 o 90 días, según la política.

Los plazos en cripto pueden ser más cortos cuando hay fondos activos en riesgo.

Un exploit de contrato inteligente puede requerir respuesta de emergencia en minutos u horas.

Una actualización de protocolo puede requerir acción multisig, una votación de gobernanza, una demora de timelock, una migración de liquidez o un periodo de retirada de usuarios.

Esto hace que los cronogramas de divulgación sean más complicados en Web3.

Si la divulgación se produce antes de que termine un timelock, los atacantes pueden explotar el problema conocido antes de que se ejecute la corrección.

Si la divulgación se retrasa demasiado, los usuarios pueden continuar depositando sin saberlo en contratos vulnerables.

Una buena política explica las excepciones de emergencia, las expectativas de embargo, las actualizaciones para investigadores y las normas de divulgación pública.

La claridad de los plazos reduce los conflictos entre investigadores y proyectos.

Whitehats y puerto seguro

Un whitehat es un investigador de seguridad que pretende ayudar a proteger a los usuarios y sistemas en lugar de explotarlos de forma maliciosa.

En cripto, los whitehats se enfrentan en ocasiones a decisiones difíciles durante exploits activos, ya que los fondos on-chain pueden vaciarse rápidamente.

Algunas situaciones pueden requerir acciones de rescate de emergencia, pero estas acciones pueden generar riesgo legal y ético si no están claramente autorizadas.

El marco SEAL Whitehat Safe Harbor describe un marco legal y técnico que permite a los protocolos preautorizar a los whitehats para intervenir durante exploits activos, rescatar fondos y devolverlos conforme a reglas definidas.

El texto de puerto seguro ayuda a reducir la incertidumbre de los investigadores éticos.

También ayuda a los protocolos a definir qué acciones de emergencia están permitidas antes de que se produzca una crisis.

Sin puerto seguro, un whitehat que mueve fondos para proteger a los usuarios podría seguir afrontando riesgo legal.

Con un puerto seguro claro, el protocolo puede establecer de antemano límites, normas de devolución, requisitos de información y protecciones legales.

Riesgos legales y éticos

La divulgación de vulnerabilidades puede implicar riesgo legal tanto para investigadores como para proyectos.

Un investigador puede infringir leyes, condiciones de servicio, normas sobre uso indebido de sistemas informáticos, normas de privacidad o reglas contra la elusión si las pruebas no están autorizadas.

Un proyecto puede generar riesgos amenazando a los investigadores, ignorando informes, no advirtiendo a los usuarios o gestionando mal los datos personales.

Por ello, las políticas de divulgación deberían definir claramente las pruebas autorizadas.

Los investigadores deben evitar pruebas destructivas, robo de datos, denegación de servicio, ingeniería social y movimiento de fondos reales, salvo autorización explícita.

Los investigadores deben informar rápidamente y conservar pruebas mínimas.

Los proyectos deben responder con respeto y evitar tratar los informes de buena fe como ataques.

Las criptomonedas añaden complejidad legal porque los fondos pueden moverse entre fronteras y los protocolos pueden estar gobernados por DAOs o fundaciones.

Una política clara no puede eliminar todos los riesgos legales, pero puede reducir la confusión y mejorar la confianza.

La protección legal de los whitehats debería planificarse antes de que una vulnerabilidad se convierta en una emergencia.

Divulgación para DAOs

Las DAO necesitan procesos especiales de divulgación de vulnerabilidades porque la toma de decisiones puede ser pública, lenta y basada en la gobernanza.

La guía oficial sobre DAO de Ethereum describe las DAO como organizaciones nativas de internet propiedad colectiva de sus miembros y gestionadas por ellos.

La gobernanza pública es valiosa, pero debatir públicamente una vulnerabilidad crítica sin parchear puede ser peligroso.

Una DAO puede necesitar un consejo de seguridad privado, multisig de emergencia, comité de bug bounty o grupo de divulgación con acceso limitado.

Este grupo puede realizar el triaje de informes sensibles antes de un debate público completo.

La DAO puede seguir publicando postmortems e informes de rendición de cuentas después de proteger a los usuarios.

El principal reto consiste en equilibrar la transparencia y la seguridad operativa.

Si cada corrección requiere una propuesta pública, los atacantes pueden explotar el problema antes de que concluya la gobernanza.

Si cada acción de emergencia es secreta, los usuarios pueden perder la confianza.

Una DAO madura define poderes de emergencia, normas de divulgación, obligaciones de los firmantes y expectativas de información pública antes de una crisis.

Divulgación para protocolos DeFi

Los protocolos DeFi necesitan una respuesta de divulgación rápida porque los activos pueden vaciarse o manipularse directamente on-chain.

La guía oficial de Ethereum sobre DeFi explica que las finanzas descentralizadas utilizan blockchains públicas y contratos inteligentes para ofrecer productos y servicios financieros.

Una vulnerabilidad DeFi puede afectar a pools de liquidez, mercados de préstamos, cálculos de colateral, participaciones de vaults, oráculos, lógica de liquidación, contabilidad de recompensas, contratos de staking o controles de gobernanza.

La componibilidad dificulta la situación porque un protocolo vulnerable puede estar integrado en muchos otros protocolos.

La respuesta de divulgación DeFi debería identificar rápidamente las integraciones posteriores.

Debería evaluar si deben pausarse los depósitos.

Debería decidir si es necesaria una retirada de emergencia, actualización de contrato, cambio de oráculo o migración de liquidez.

Debería coordinarse con auditores y socios de seguridad cuando sea posible.

Debería comunicar lo suficiente para proteger a los usuarios sin revelar instrucciones de exploit demasiado pronto.

Después de la corrección, el protocolo debería explicar claramente la causa raíz y el impacto para los usuarios.

Divulgación para wallets y aplicaciones Web3

Las vulnerabilidades de wallets y aplicaciones Web3 pueden perjudicar a los usuarios incluso si los contratos inteligentes no presentan fallos.

Un error de wallet puede mostrar detalles de transacción incorrectos.

Un error de frontend de una dApp puede dirigir a los usuarios al contrato equivocado.

Un error de conexión de wallet puede aprobar la cadena o método incorrectos.

Un error de simulación de transacciones puede ocultar un movimiento peligroso de activos.

Un error de extensión de navegador puede exponer datos sensibles.

Una dependencia comprometida puede inyectar código destinado a vaciar wallets.

La guía oficial de seguridad de Ethereum explica que los usuarios deben proteger el acceso a sus wallets, las claves privadas y las frases de recuperación.

La divulgación de vulnerabilidades de wallets debe gestionarse con extrema precaución porque los usuarios dependen de las interfaces de wallet para entender qué están firmando.

Un equipo de wallet debería contar con un contacto de seguridad claro, un proceso de actualización rápido, un plan de comunicación sobre riesgos de firma y un sistema de alertas para usuarios.

Una aplicación Web3 no debería asumir que las auditorías de contratos son suficientes si el frontend puede verse comprometido.

Divulgación pública y postmortems

La divulgación pública debería ayudar a los usuarios a entender qué ocurrió, qué se vio afectado, qué se corrigió y qué medidas deben tomar.

Un buen postmortem explica el tipo de vulnerabilidad.

Explica el cronograma.

Explica los contratos o sistemas afectados.

Explica si los fondos estuvieron en riesgo o se perdieron.

Explica la corrección.

Explica qué deben hacer los usuarios a continuación.

Explica qué mejorará el equipo.

Reconoce a los investigadores cuando sea apropiado y esté permitido.

Evita publicar detalles que permitan un exploit antes de que los usuarios estén protegidos.

La divulgación pública es importante porque los usuarios cripto a menudo deben decidir si retirar, migrar, revocar aprobaciones, actualizar wallets, evitar un frontend o supervisar una dirección.

El silencio puede ser perjudicial porque deja a los usuarios con dudas.

Una divulgación clara genera confianza incluso cuando la vulnerabilidad es grave.

Qué deben incluir los investigadores en un informe

Un informe de vulnerabilidad sólido debe ser claro, factual y reproducible.

Debe incluir el proyecto, componente, contrato, commit, endpoint, versión de wallet, cadena o dirección afectados.

Debe describir la vulnerabilidad en lenguaje sencillo.

Debe explicar el impacto.

Debe incluir pasos de prueba de concepto que eviten daños reales a los usuarios.

Debe incluir el comportamiento esperado y el comportamiento real.

Debe incluir capturas de pantalla, registros, transacciones de prueba, resultados de pruebas locales o fragmentos de código cuando sean útiles.

Debe explicar si los fondos están en riesgo.

Debe explicar si el problema parece explotable en mainnet.

Debe evitar secretos innecesarios, datos de usuarios y explotación activa.

Un buen informe ayuda al equipo a reproducir y corregir el problema rápidamente.

Qué deben hacer los proyectos tras recibir un informe

Un proyecto debería confirmar rápidamente la recepción del informe.

Debería asignar un responsable de seguridad.

Debería verificar las afirmaciones del investigador en un entorno seguro.

Debería evaluar la gravedad y los sistemas afectados.

Debería conservar las pruebas.

Debería evitar el debate público antes de contar con un plan de protección.

Debería preparar una corrección o mitigación.

Debería coordinarse con los integradores afectados si fuese necesario.

Debería pagar recompensas conforme a la política de bounty cuando corresponda.

Debería comunicarse respetuosamente con el investigador.

Debería publicar una divulgación o postmortem cuando los usuarios estén protegidos.

Un proyecto que ignora los informes crea riesgos para los usuarios y perjudica la confianza de los investigadores.

Beneficios de la divulgación de vulnerabilidades

El primer beneficio de la divulgación de vulnerabilidades es la protección de los usuarios.

Los fallos de seguridad pueden corregirse antes de que los atacantes los exploten.

El segundo beneficio es la confianza de los investigadores.

Los whitehats tienen más probabilidades de informar de problemas cuando el proceso es claro y justo.

El tercer beneficio es la resiliencia del protocolo.

Los proyectos aprenden de las debilidades y mejoran su arquitectura de seguridad.

El cuarto beneficio es la transparencia.

Los usuarios pueden comprender los riesgos reales después de que se resuelvan los problemas.

El quinto beneficio es la seguridad del ecosistema.

Los protocolos integrados, wallets y proveedores de infraestructura pueden coordinarse cuando las vulnerabilidades afectan a múltiples sistemas.

El sexto beneficio es la claridad legal.

Las políticas y el texto de puerto seguro reducen la incertidumbre para los investigadores de buena fe.

El séptimo beneficio es una mejor cultura de seguridad.

Los proyectos que reciben positivamente los informes tienen más probabilidades de mejorar de forma continua.

Riesgos de una divulgación deficiente de vulnerabilidades

El primer riesgo es la aceleración de exploits.

Los detalles públicos divulgados demasiado pronto pueden ayudar a los atacantes a robar fondos.

El segundo riesgo es el daño a los usuarios.

Una respuesta retrasada puede dejar expuestos a los usuarios.

El tercer riesgo es la frustración de los investigadores.

Los investigadores pueden dejar de informar si los proyectos los ignoran o amenazan.

El cuarto riesgo es el conflicto legal.

Las normas poco claras pueden generar disputas entre whitehats y equipos de proyecto.

El quinto riesgo es el daño reputacional.

Los usuarios pueden perder la confianza si un proyecto oculta vulnerabilidades graves o se comunica mal.

El sexto riesgo es la confusión en la gobernanza.

Las DAO pueden tener dificultades para actuar con rapidez si no existe un proceso de divulgación de emergencia.

El séptimo riesgo es el daño a la componibilidad.

Una vulnerabilidad en un protocolo puede propagar el riesgo a través de integraciones antes de que se advierta a otros.

Malentendidos habituales sobre la divulgación de vulnerabilidades

Un malentendido es que la divulgación de vulnerabilidades implica publicar inmediatamente los detalles de un exploit.

Una buena divulgación suele comenzar de forma privada para que el equipo afectado pueda proteger primero a los usuarios.

Otro malentendido es que un bug bounty significa automáticamente que un proyecto es seguro.

Una recompensa ayuda a recibir informes, pero no sustituye auditorías, supervisión, pruebas y respuesta a incidentes.

Un tercer malentendido es que todo movimiento de fondos realizado por un whitehat es seguro.

Mover fondos sin autorización puede generar riesgo legal y ético incluso cuando las intenciones son buenas.

Un cuarto malentendido es que solo los contratos inteligentes necesitan divulgación.

Las wallets, frontends, API, sistemas RPC, bridges, oráculos, validadores y sistemas de gobernanza también pueden contener vulnerabilidades graves.

Un quinto malentendido es que la divulgación termina tras un parche.

Los usuarios pueden seguir necesitando instrucciones de migración, orientación para revocar aprobaciones, actualizaciones de wallet o detalles de un postmortem.

Un sexto malentendido es que la transparencia pública y la coordinación privada son opuestas.

Un proceso maduro puede coordinarse primero de forma privada y divulgar públicamente después de establecer la protección.

Divulgación de vulnerabilidades en términos sencillos

La divulgación de vulnerabilidades consiste en informar de un error de seguridad de forma segura y organizada.

En cripto, este proceso protege fondos reales y usuarios reales.

Un investigador descubre una debilidad.

El investigador informa de ella a través del canal oficial.

El proyecto confirma el problema.

El proyecto corrige o mitiga el problema.

El proyecto se comunica con los usuarios cuando es seguro hacerlo.

Si existe un bug bounty, el investigador puede recibir una recompensa.

Si existe puerto seguro, el investigador puede disponer de una protección legal más clara para las acciones de buena fe.

Para los principiantes, la regla principal es sencilla.

Una buena divulgación de vulnerabilidades ayuda a corregir errores antes de que los atacantes los conviertan en pérdidas.

Preguntas frecuentes

¿Qué es la divulgación de vulnerabilidades?

La divulgación de vulnerabilidades es el proceso de informar, validar, corregir y comunicar una debilidad de seguridad en software, contratos inteligentes, wallets, protocolos o infraestructura Web3.

¿Qué es la divulgación coordinada de vulnerabilidades?

La divulgación coordinada de vulnerabilidades es un proceso estructurado en el que investigadores, proveedores, equipos de proyecto y, en ocasiones, coordinadores colaboran antes de la divulgación pública.

¿Por qué es importante la divulgación de vulnerabilidades en cripto?

Es importante porque las vulnerabilidades cripto pueden afectar directamente a los fondos de los usuarios, tesorerías de protocolos, contratos inteligentes, bridges, wallets y sistemas de gobernanza.

¿Es la divulgación de vulnerabilidades lo mismo que un bug bounty?

No. La divulgación de vulnerabilidades es el proceso de información y respuesta, mientras que un bug bounty es un programa de recompensas por informes de seguridad válidos.

¿Qué debe incluir un informe de vulnerabilidad cripto?

Debe incluir los sistemas afectados, el impacto, los pasos de reproducción, pruebas de concepto, detalles de la cadena o contrato y recomendaciones seguras que no perjudiquen a los usuarios.

¿Deben los investigadores divulgar públicamente un error de contrato inteligente de inmediato?

Normalmente no, porque los detalles públicos de un exploit pueden ayudar a los atacantes a robar fondos antes de que el proyecto pueda proteger a los usuarios.

¿Qué es la divulgación responsable?

La divulgación responsable suele consistir en informar de una vulnerabilidad de forma privada y dar al equipo afectado tiempo para resolverla antes de publicar los detalles.

¿Qué es la divulgación completa?

La divulgación completa consiste en compartir públicamente los detalles de una vulnerabilidad, de inmediato o tras una fecha límite.

¿Qué es una política de divulgación de vulnerabilidades?

Una política de divulgación de vulnerabilidades indica a los investigadores qué está dentro del alcance, cómo informar de problemas, qué pruebas están permitidas y cómo se gestionará la divulgación.

¿Qué es security.txt?

Security.txt es un formato de archivo estandarizado que ayuda a las organizaciones a publicar información de contacto para informar de vulnerabilidades y sus prácticas de divulgación.

¿Qué es un whitehat en cripto?

Un whitehat es un investigador de seguridad que trata de proteger a los usuarios y sistemas informando de vulnerabilidades o ayudando en defensas autorizadas.

¿Qué es el puerto seguro?

El puerto seguro es texto de política o legal que ofrece una protección más clara a investigadores de buena fe cuando siguen reglas definidas.

¿Pueden los whitehats mover fondos de un protocolo durante un exploit?

Solo deberían hacerlo cuando esté claramente autorizado por un puerto seguro, proceso de emergencia u otro permiso válido, ya que el movimiento no autorizado de fondos puede generar riesgo legal.

¿Sustituyen las auditorías de contratos inteligentes a la divulgación de vulnerabilidades?

No. Las auditorías reducen el riesgo antes de la implementación, mientras que la divulgación gestiona las vulnerabilidades encontradas después de la implementación o fuera del periodo de auditoría.

¿Necesitan las DAO políticas de divulgación de vulnerabilidades?

Sí. Las DAO necesitan vías claras de información privada, reglas de autoridad de emergencia, procedimientos para firmantes y expectativas de divulgación pública.

¿Qué ocurre después de corregir una vulnerabilidad?

El proyecto debería comunicar el impacto para los usuarios, publicar un postmortem o aviso cuando sea seguro, reconocer a los investigadores cuando corresponda y mejorar los controles.

¿Puede una divulgación de vulnerabilidad ser una estafa?

Sí. Los atacantes pueden enviar informes falsos, archivos maliciosos, mensajes de extorsión o enlaces de phishing, por lo que los proyectos deben realizar el triaje de los informes de forma segura.

¿Cuál es el mejor proceso de divulgación de vulnerabilidades para proyectos Web3?

El mejor proceso incluye un canal de información claro, un alcance definido, triaje rápido, clasificación de gravedad, reglas de bug bounty, texto de puerto seguro, respuesta de emergencia y postmortems transparentes.

Conclusión

La divulgación de vulnerabilidades es un proceso de seguridad fundamental para la industria cripto.

Ofrece a los investigadores una forma segura de informar de debilidades antes de que los atacantes las exploten.

Ofrece a los equipos de protocolo una vía estructurada para confirmar, corregir, mitigar y comunicar problemas de seguridad.

Ofrece a los usuarios mayor protección y mejor información sobre sistemas que pueden custodiar sus activos.

En Web3, la divulgación es más urgente que en muchos entornos de software tradicionales porque el código vulnerable puede controlar directamente fondos activos.

Un error en un contrato inteligente, un fallo de bridge, un problema de wallet, una debilidad de oráculo, un error de gobernanza o el compromiso de un frontend pueden causar pérdidas graves con gran rapidez.

Por ello, los proyectos cripto necesitan políticas de divulgación claras, contactos de seguridad, programas de bug bounty, flujos de trabajo de triaje, planes de emergencia y prácticas de postmortem.

Las DAO y los protocolos DeFi también necesitan vías de coordinación privada porque una gobernanza totalmente pública puede revelar detalles peligrosos antes de que las correcciones estén listas.

Los whitehats necesitan canales seguros para informar y claridad legal.

Los usuarios necesitan una comunicación honesta después de que se reduzca el riesgo.

Los equipos de seguridad necesitan autoridad suficiente para actuar rápidamente.

La divulgación de vulnerabilidades no es una señal de que un proyecto sea débil.

Es una señal de que un proyecto tiene la madurez suficiente para afrontar la realidad de la seguridad.

En términos sencillos, los mejores proyectos cripto no fingen que las vulnerabilidades nunca ocurrirán.

Se preparan para ellas, reciben positivamente los informes de buena fe, corrigen los problemas con rapidez y divulgan la información claramente cuando los usuarios están protegidos.