Divulgar fallos sin acabar en el juzgado: por qué la UE sigue llegando tarde al CVD

Descubrir una vulnerabilidad en Europa sigue siendo, en demasiados casos, una actividad extrañamente ambigua: puede reforzar la seguridad colectiva o meterte en un problema legal si el marco de divulgación no está claro. Ahí está el verdadero debate sobre coordinated vulnerability disclosure (CVD). No va de romanticismo hacker. Va de gobernanza, de incentivos y de responsabilidad jurídica.

La cuestión importa porque la UE ha llenado el tablero de obligaciones de ciberseguridad, reporte de incidentes y gestión de riesgos, pero la parte más incómoda sigue siendo la misma: qué ocurre cuando alguien ajeno a la organización encuentra un fallo y decide comunicarlo. Si ese canal no existe, si el lenguaje legal es confuso o si la empresa reacciona a la defensiva, el resultado no suele ser resiliencia. Suele ser silencio, retraso o conflicto.

Eso explica por qué la divulgación coordinada de vulnerabilidades ha ido ganando peso en el discurso regulatorio europeo. No hace falta exagerarlo ni vestirlo de revolución. Basta mirar cómo distintas piezas normativas y de política pública empujan en la misma dirección: más capacidad para detectar fallos, más obligaciones de gestión del riesgo y más presión para demostrar que la organización sabe recibir, evaluar y corregir vulnerabilidades sin convertir ese proceso en una batalla con quien las reporta.

El punto de inflexión no está en una consigna política, sino en obligaciones muy concretas

La base jurídica más clara está en la Directiva NIS2. Su artículo 21 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de la seguridad de redes y sistemas de información. Entre esas medidas aparece, de forma expresa, la gestión y divulgación de vulnerabilidades. No es una nota al pie. Está dentro del núcleo de la gestión de riesgos.

Eso cambia el tono de la conversación. Durante años, muchos programas de CVD se presentaban como una buena práctica voluntaria, algo recomendable si la organización tenía madurez suficiente o si su equipo jurídico no entraba en pánico al leer la palabra “researcher”. Con NIS2, la conversación se vuelve menos estética y más operativa: si debes gestionar vulnerabilidades de forma adecuada, necesitas un mecanismo razonable para recibir información sobre fallos, validarla y actuar. Lo contrario sería una versión bastante creativa —y poco convincente— del cumplimiento.

La propia arquitectura de NIS2 apunta hacia esa lógica. El artículo 23 fija obligaciones de notificación de incidentes significativos con plazos exigentes, y el artículo 29 atribuye a los Estados miembros la tarea de promover y facilitar la divulgación coordinada de vulnerabilidades. Esa combinación es reveladora. Bruselas no se limita a decir a las organizaciones “gestiona mejor tus riesgos”; también asume que la detección temprana de fallos y la coordinación con terceros forman parte del ecosistema de seguridad.

Aquí aparece una de las paradojas regulatorias más europeas del momento: se exige rapidez en la gestión de incidentes, pero no siempre existe el mismo grado de claridad jurídica para quienes ayudan a detectar los fallos antes de que esos incidentes ocurran. Es como exigir extintores, simulacros y planes de evacuación mientras se deja en un limbo a quien avisa de que el edificio huele a quemado.

CVD no es un gesto de transparencia. Es una pieza de control interno

Conviene decirlo sin vueltas: un programa de divulgación coordinada bien diseñado se parece más a un control de segunda línea que a una campaña de relaciones públicas. Su función no es quedar bien ante la comunidad técnica. Su función es reducir tiempo de exposición, ordenar la recepción de hallazgos, fijar expectativas y evitar que una vulnerabilidad acabe escalando por puro caos procesal.

Eso tiene consecuencias prácticas para compliance, seguridad, tecnología y asesoría jurídica. Cuando una organización publica una política de CVD, está definiendo al menos cinco cosas que importan de verdad:

• qué sistemas entran en alcance y cuáles no;
• qué conductas de prueba considera permitidas o no autorizadas;
• por qué canal debe reportarse una vulnerabilidad;
• qué plazos internos maneja para reconocer, evaluar y responder;
• qué compromiso ofrece respecto al trato del investigador que actúe de buena fe.

Sin esos elementos, la “política” suele ser un buzón genérico decorado con lenguaje vago. Y un buzón vago no coordina nada. Solo traslada el problema al primer abogado o al primer administrador de sistemas que reciba el correo.

Por eso la divulgación coordinada no debería tratarse como un anexo menor de la política de seguridad. Si la entidad está sujeta a NIS2, el encaje lógico está en la gobernanza del riesgo del artículo 21. Si, además, opera en sectores intensamente regulados o críticos, el CVD se cruza con gestión de terceros, respuesta a incidentes, trazabilidad de remediación y, en algunos casos, notificación regulatoria posterior. La vulnerabilidad descubierta por un tercero puede terminar siendo el primer eslabón de una cadena documental que acabe en un supervisor. Más vale que esa cadena exista.

Lo que sí puede decirse sobre ENISA sin pasarse de frenada

En este debate se cita mucho a ENISA, a veces con precisión y a veces con entusiasmo. Lo prudente es separar lo acreditado de lo adornado. ENISA ha trabajado de forma sostenida en marcos y buenas prácticas de divulgación coordinada de vulnerabilidades, y ha publicado materiales orientados a ayudar a organizaciones y autoridades a estructurar estos procesos. Esa labor encaja con el mandato europeo de reforzar la capacidad colectiva de gestión de vulnerabilidades y de fomentar enfoques coordinados entre actores públicos y privados.

Lo que resulta más sólido, desde el punto de vista regulatorio, es que el trabajo de ENISA ha contribuido a normalizar la idea de que la divulgación coordinada necesita procedimientos, roles definidos y canales claros. Es una conclusión compatible con las obligaciones de gestión del riesgo en NIS2 y con la necesidad práctica de recibir hallazgos externos sin improvisación.

Donde conviene bajar un poco el volumen es en afirmaciones excesivamente específicas sobre supuestas peticiones de reforma penal o reclamaciones muy concretas atribuidas a ENISA si no se dispone de una fuente textual clara. El problema jurídico existe, sí: los investigadores pueden enfrentarse a incertidumbre sobre los límites entre prueba legítima, acceso no autorizado y exposición a responsabilidad. Pero una cosa es identificar esa tensión y otra atribuir a una agencia una propuesta normativa exacta que no esté bien documentada.

Dicho de otra manera: la discusión sobre safe harbour, protección del investigador de buena fe y seguridad jurídica está plenamente justificada por el funcionamiento real de la divulgación coordinada. Lo que no conviene hacer es inflar el expediente con formulaciones que no puedas sostener ante un verificador de hechos o, peor aún, ante un lector que sí ha leído los documentos originales.

El agujero jurídico sigue ahí, aunque lo describas sin hipérboles

Una política de CVD sin algún tipo de protección o expectativa razonable para el investigador funciona regular. Muy regular. Si la organización pide que se reporten vulnerabilidades pero se reserva un margen total para tratar cualquier prueba técnica como conducta hostil, el incentivo se rompe. El mensaje implícito pasa a ser este: “Ayúdanos, pero bajo tu propio riesgo”. No es un gran diseño institucional.

Ese problema no requiere inventar propuestas normativas para ser real. Basta observar la mecánica del proceso. Para verificar una vulnerabilidad, el investigador suele interactuar con sistemas, servicios o aplicaciones de la organización. Incluso si actúa con contención y sin explotación destructiva, pueden surgir preguntas delicadas: qué pruebas eran necesarias, qué volumen de interacción era aceptable, si hubo acceso a datos, si se rebasó un límite técnico o contractual, o si la empresa había publicado condiciones suficientes para autorizar ese tipo de actividad.

La dificultad aumenta cuando la entidad carece de política pública o mantiene textos internamente contradictorios. Un departamento de seguridad puede querer recibir reportes. El equipo legal puede temer abrir la puerta a accesos no autorizados. Comunicación puede ver un riesgo reputacional. Tecnología puede no tener recursos para validar hallazgos con rapidez. El resultado ya se conoce: silencio inicial, respuestas defensivas y una remediación más lenta de lo que admitiría cualquier manual sensato de gestión del riesgo.

La salida no depende solo del legislador. Las organizaciones tienen margen para reducir esa fricción ahora mismo, con tres decisiones bastante terrenales:

• publicar una política de CVD comprensible, específica y visible;
• definir un compromiso de actuación de buena fe respecto a investigadores que respeten esa política;
• alinear a seguridad, legal y negocio antes de que llegue el primer hallazgo serio.

La tercera suele fallar más que la primera. Muchas entidades publican un correo tipo security@ y creen haber resuelto el expediente. No lo han resuelto. Solo han creado un punto de entrada. Lo difícil viene después: triage, validación, priorización, corrección, coordinación de plazos y decisión sobre comunicación externa.

NIS2 obliga a gestionar vulnerabilidades. No te regala un proceso maduro

Aquí está uno de los errores más repetidos en compliance tecnológico: confundir obligación legal con capacidad operativa. NIS2, por sí sola, no convierte a una organización en receptora competente de vulnerabilidades. El artículo 21 impone el qué. El cómo sigue dependiendo del diseño interno, de los recursos y de una cadena de decisión que funcione cuando el correo incómodo aterriza un viernes por la tarde.

Para que el CVD sea algo más que una declaración ornamental, la entidad necesita traducir esa obligación general en controles concretos. Al menos estos:

• un canal seguro y monitorizado para reportes;
• criterios de severidad y plazos de respuesta internos;
• registro trazable de hallazgos, decisiones y remediación;
• escalado jurídico cuando la prueba pueda haber afectado a datos personales, confidencialidad o disponibilidad;
• integración con el proceso de gestión de incidentes cuando la vulnerabilidad ya haya sido explotada.

Ese último punto conecta NIS2 con otra pieza regulatoria que a veces se trata por separado cuando no debería: GDPR. Si la vulnerabilidad reportada implica una violación de seguridad de los datos personales, entra en juego el artículo 33 del RGPD sobre notificación a la autoridad de control sin dilación indebida y, cuando sea posible, a más tardar en 72 horas tras tener constancia. Si el riesgo para los derechos y libertades es alto, el artículo 34 puede exigir además comunicación a los afectados.

La frontera entre “vulnerabilidad” e “incidente” no siempre es limpia. Un hallazgo externo puede revelar una debilidad teórica, un acceso real no malicioso o una exposición efectiva de datos. Tu proceso de CVD debe saber distinguir esos escenarios. Si no lo hace, el problema ya no es de comunicación con investigadores. Es de cumplimiento cruzado entre seguridad y privacidad.

El cruce con DORA: el sector financiero no puede permitirse políticas decorativas

En entidades financieras, el debate se vuelve todavía menos académico. DORA no regula la divulgación coordinada de vulnerabilidades como una categoría autónoma, pero sí exige una gobernanza mucho más disciplinada de riesgos TIC, incidentes, pruebas y terceros. Y eso hace que un canal de recepción de vulnerabilidades externas deje de ser un detalle simpático para convertirse en una fuente potencial de obligaciones y evidencia.

El artículo 6 de DORA obliga a las entidades financieras a contar con un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo TIC. El artículo 8 entra en identificación, clasificación y documentación de funciones, activos de información y dependencias TIC. El artículo 10 se centra en detección de actividades anómalas. Los artículos 17 y siguientes desarrollan la gestión, clasificación y notificación de incidentes graves relacionados con las TIC. Y los artículos 28 y siguientes aprietan el tornillo sobre el riesgo derivado de terceros prestadores de servicios TIC.

Traducido al mundo real: si una vulnerabilidad reportada por un tercero afecta a un servicio crítico soportado por un proveedor, la entidad no solo tiene que remediar el fallo. Tiene que entender si la debilidad afecta a su mapa de funciones críticas, si activa obligaciones de escalado interno, si compromete controles sobre terceros y si puede derivar en incidente notificable. DORA no te pregunta si la vulnerabilidad llegó por un bug bounty, por un correo espontáneo o por una llamada incómoda. Te preguntará si tu marco de control reaccionó de forma trazable y proporcionada.

Ahí aparece otro detalle incómodo: muchas entidades financieras han trabajado mejor el frente de third-party risk que el de recepción estructurada de hallazgos externos. Tienen matrices, cláusulas contractuales y catálogos de servicios. Pero no siempre tienen una política pública nítida para que un investigador comunique una debilidad sin caer en un limbo legal o operativo. La asimetría es llamativa. Se supervisa al proveedor con lupa y, al mismo tiempo, se deja difuso el mecanismo para enterarse antes de que el problema estalle.

No confundas CVD con bug bounty. Se parecen menos de lo que algunos venden

Otro punto que conviene limpiar de ruido: divulgación coordinada y programas de recompensas no son sinónimos. Un programa de CVD puede existir sin incentivos económicos, y de hecho muchas organizaciones empiezan así. Lo esencial no es pagar. Lo esencial es establecer una vía de reporte, un marco de interacción y una expectativa razonable de respuesta.

Un bug bounty añade otra capa: define perímetros de prueba, reglas de participación, criterios de elegibilidad y, en su caso, compensación por hallazgos válidos. Eso puede aumentar volumen y calidad de los reportes, pero también exige una madurez jurídica y operativa mayor. Si ni siquiera sabes gestionar bien cinco hallazgos espontáneos al año, lanzar recompensas puede ser una manera eficaz de descubrir tus carencias en público.

Por eso conviene no presentar los programas de recompensas como sustituto de un marco jurídico o de gobernanza interna. Sin política clara, sin triage competente y sin alineamiento con legal, pagar por vulnerabilidades solo acelera la llegada de problemas que no sabes procesar. El incentivo económico no arregla un diseño institucional torpe. A veces lo deja más en evidencia.

La pregunta útil no es “¿debemos tener bug bounty?”. La pregunta útil es otra: “¿podemos recibir, evaluar y corregir reportes externos con consistencia, trazabilidad y seguridad jurídica básica?”. Si la respuesta es no, el orden lógico es empezar por una política de CVD seria. El marketing de las recompensas puede esperar.

La pieza olvidada: texto legal comprensible para humanos, no solo para abogados

Buena parte del fracaso de algunas políticas de divulgación no se debe a la ausencia de intención, sino a la redacción. Hay documentos que parecen escritos para disuadir precisamente al tipo de persona que la organización necesita que escriba: alguien que ha encontrado un fallo y quiere saber, en dos minutos, si reportarlo le traerá problemas.

Una política útil no necesita florituras. Necesita precisión. Debe decir qué sistemas están dentro del alcance, qué actividades están prohibidas de forma expresa, qué espera la entidad del investigador, qué hará la entidad al recibir el reporte y qué tratamiento dará a la información. Si ofrece algún compromiso de no emprender acciones cuando se actúe de buena fe y conforme a la política, mejor decirlo con claridad y no enterrarlo entre veinte cláusulas defensivas.

También conviene evitar la contradicción clásica entre la política de CVD y otros textos públicos. Si tus condiciones de uso prohíben de forma absoluta cualquier prueba o acceso automatizado, mientras tu política de divulgación invita a reportar fallos con cierta verificación técnica, has creado una colisión documental. En caso de conflicto, esa ambigüedad no ayuda a nadie. Ni al investigador, ni al equipo legal, ni a la propia organización si luego debe explicar qué autorizaba exactamente.

Este punto parece menor hasta que llega el caso difícil. Entonces deja de ser menor. El lenguaje público de la entidad puede convertirse en la principal referencia para valorar si existía una expectativa razonable de permiso, cooperación o tolerancia respecto a determinadas conductas de prueba limitadas. No es un detalle cosmético. Es arquitectura de riesgo.

Cómo debería reaccionar una organización cuando recibe un hallazgo serio

El proceso maduro no empieza con la remediación técnica. Empieza con clasificación. La entidad debe responder con rapidez suficiente para reconocer recepción, pedir información adicional si hace falta y evitar que el investigador concluya que le han ignorado. Parece básico. Sorprendentemente, no siempre ocurre.

Después viene el triage. Aquí se separan las políticas serias de los buzones decorativos. Hay que determinar si el hallazgo es reproducible, qué activos afecta, si existen controles compensatorios, si se ha producido explotación, si puede haber implicación de datos personales y si el problema depende de un tercero TIC. Ese análisis debería quedar documentado, porque en sectores regulados la trazabilidad no es un lujo. Es defensa propia.

Si la vulnerabilidad está confirmada, toca fijar una ventana de remediación razonable y coordinar la comunicación con quien la reportó. “Coordinada” significa precisamente eso: ni divulgación precipitada que aumente riesgo, ni silencio indefinido por comodidad corporativa. El equilibrio depende del tipo de fallo, del impacto y de la posibilidad real de explotación. No hay una cifra mágica universal que sirva para todos los casos, y fingir que la hay suele ser una forma elegante de no pensar.

Cuando además existe exposición potencial de datos personales, el proceso debe cruzarse con el análisis del RGPD. Y si la entidad está en ámbito NIS2 o DORA, también con los criterios internos sobre incidentes significativos o graves. Un hallazgo externo puede ser el detonante de varias obligaciones paralelas. Si cada equipo trabaja en su propio carril, los errores de coordinación aparecen muy deprisa.

El problema cultural sigue siendo tan relevante como el jurídico

Hay empresas que aceptan mejor una auditoría intrusiva pagada a un proveedor que un correo gratuito señalando una vulnerabilidad real. Resulta casi cómico, pero ocurre. Parte del problema es cultural: se sigue viendo al investigador externo como una fuente de riesgo reputacional antes que como una señal temprana de riesgo operativo.

Esa mentalidad choca frontalmente con la lógica regulatoria actual. NIS2 gira sobre gestión del riesgo y preparación. DORA gira sobre resiliencia operativa, gobernanza y capacidad de respuesta. GDPR exige valorar impacto real sobre derechos y libertades cuando hay afectación de datos. Ninguna de esas normas premia el orgullo herido. Lo que premian —o exigen, mejor dicho— es capacidad de detectar, entender y corregir.

Tu organización puede tener un SOC impecable, una batería de controles y una presentación preciosa para el consejo. Si un tercero comunica una vulnerabilidad seria y la respuesta interna es improvisación, amenaza legal automática o semanas de silencio, hay un problema de madurez. Y no lo arregla una política copiada de internet.

También conviene decir algo incómodo para algunos equipos de seguridad: no todo investigador actúa de manera impecable, y no toda autoproclamada investigación ética lo es. Precisamente por eso hacen falta políticas concretas, límites claros y un proceso de validación robusto. La existencia de casos grises no desacredita la divulgación coordinada. La vuelve más necesaria.

Qué debería revisar ahora mismo una entidad sujeta a NIS2 o DORA

Si la organización quiere pasar del discurso al control efectivo, hay cinco preguntas que no admiten mucha evasiva.

• ¿Existe una política pública de divulgación coordinada? Si no existe, la entidad depende de canales improvisados. Si existe pero es genérica, probablemente también.
• ¿Está alineada con NIS2 art. 21? La gestión y divulgación de vulnerabilidades no debería aparecer como ocurrencia aislada, sino como parte del sistema de gestión de riesgos.
• ¿Cruza con incident response y privacidad? Un reporte de vulnerabilidad puede activar análisis bajo NIS2 art. 23 y, si hay datos personales comprometidos, RGPD art. 33 y 34.
• ¿Contempla dependencias de terceros TIC? En ámbito financiero, DORA art. 28 y siguientes obligan a mirar el riesgo de terceros con bastante más disciplina de la que muchas políticas de CVD reflejan hoy.
• ¿Hay compromiso interno previo entre seguridad, legal y negocio? Sin ese acuerdo, la primera vulnerabilidad compleja se convierte en una discusión de competencias en mitad del incendio.

Este chequeo no requiere esperar a una guía adicional ni a una nueva ronda de PowerPoint regulatorio. Requiere sentar a las personas correctas, revisar textos públicos, mapear el proceso y decidir quién hace qué cuando llega el próximo hallazgo.

La dirección del viaje está clara, aunque el mapa legal siga incompleto

La divulgación coordinada de vulnerabilidades encaja cada vez mejor en la lógica de la regulación europea: gestión del riesgo, trazabilidad, cooperación y capacidad de respuesta. NIS2 lo refleja de manera explícita al incorporar la gestión y divulgación de vulnerabilidades en el artículo 21 y al pedir a los Estados miembros que faciliten la CVD en el artículo 29. DORA, sin regularla como categoría autónoma, empuja a las entidades financieras a tratar cualquier hallazgo relevante dentro de un marco exigente de gobernanza TIC e incidentes. Y el RGPD recuerda que algunas vulnerabilidades no se quedan en un problema técnico: pueden convertirse en una violación de seguridad jurídicamente relevante.

Lo que sigue faltando en muchos casos es claridad suficiente para que el investigador de buena fe no actúe en terreno resbaladizo y para que la organización no improvise su respuesta como si fuera la primera vez que alguien le señala un fallo. Esa zona gris no desaparece por hablar mucho de resiliencia. Desaparece —o al menos se reduce— con políticas concretas, lenguaje claro y procesos internos maduros.

La conclusión no necesita grandilocuencia. Si tu entidad está sometida a obligaciones serias de ciberseguridad y aún trata la divulgación coordinada como un asunto periférico, va con retraso. No porque lo diga un eslogan europeo, sino porque el propio armazón normativo ya presupone que las vulnerabilidades deben gestionarse de forma ordenada, documentada y compatible con otras obligaciones regulatorias. La pregunta no es si alguien descubrirá un fallo. La pregunta es qué hará tu organización cuando ocurra y si podrá demostrar, con algo más que buenas intenciones, que sabía cómo responder.