Vulnerability Disclosure: Responsible vs Full Disclosure

El dilema original: ¿publicar o no publicar?

Imagina que descubres una vulnerabilidad crítica en un software utilizado por millones de personas. Tienes dos opciones. La primera: publicarla inmediatamente para que todos (incluidos los atacantes) la conozcan. La segunda: contactar al fabricante en privado, esperar a que publique un parche y solo entonces revelar los detalles. Parece simple. No lo es.

Este debate, que comenzó en los años 90 y sigue activo hoy, ha definido la relación entre investigadores de seguridad, vendedores de software y los usuarios que dependen de ambos. Cada opción tiene consecuencias reales. Publicar demasiado pronto expone a millones de usuarios. Esperar demasiado permite que vendedores negligentes ignoren los problemas mientras los atacantes los explotan en silencio.

Los orígenes: Bugtraq y la era del full disclosure

Bugtraq (1993)

En 1993, Scott Chasin creó la lista de correo Bugtraq, dedicada a la discusión de vulnerabilidades de seguridad. Bugtraq adoptó una filosofía radical para la época: publicar los detalles técnicos completos de las vulnerabilidades, incluyendo código de exploit cuando fuera necesario para demostrar el problema.

La filosofía subyacente era directa: si los atacantes ya conocen la vulnerabilidad (y frecuentemente la conocían antes de que el vendedor la reconociera), la única forma de proteger a los usuarios es que ellos también la conozcan. La transparencia forzaría a los vendedores a actuar rápido.

Full-Disclosure mailing list (2002)

Cuando Bugtraq, ya bajo propiedad de SecurityFocus (y posteriormente Symantec), empezó a moderar el contenido y rechazar ciertos reportes, John Cartwright y Len Rose crearon la lista Full-Disclosure en 2002 como alternativa sin censura. La lista se convirtió en el lugar donde investigadores frustrados con vendedores no responsivos publicaban detalles completos de vulnerabilidades.

El argumento a favor del full disclosure

Los defensores del full disclosure argumentaban (y algunos siguen argumentando):

1. Los vendedores no actúan sin presión pública. Antes de Bugtraq, los vendedores ignoraban sistemáticamente los reportes de vulnerabilidades. Algunas empresas tardaban años en parchear fallos reportados en privado. La amenaza de publicación era la única presión efectiva.
2. Los atacantes ya lo saben. Las vulnerabilidades no se descubren una sola vez. Si un investigador ético la encuentra, es probable que grupos maliciosos también la hayan descubierto independientemente.
3. Los usuarios merecen saber. Sin conocer la vulnerabilidad, los usuarios no pueden tomar medidas defensivas temporales (desactivar un servicio, aplicar un workaround, restringir acceso).

El contraargumento: responsible disclosure

Microsoft y la industria responden

A principios de los 2000, la industria del software, liderada por Microsoft, articuló la posición contraria: publicar detalles de vulnerabilidades sin dar tiempo al vendedor para parchear causa más daño que beneficio. Los usuarios quedan expuestos a ataques mientras el parche se desarrolla y prueba.

Microsoft propuso el concepto de "responsible disclosure": el investigador notifica al vendedor en privado, le da un plazo razonable para desarrollar y publicar un parche, y solo entonces publica los detalles técnicos. La publicación posterior tiene valor educativo (enseña a la comunidad sobre el tipo de fallo), pero se hace cuando los usuarios ya tienen un parche disponible.

El caso eEye vs Microsoft

En 2003, la empresa de seguridad eEye Digital Security descubrió una serie de vulnerabilidades críticas en productos Microsoft. eEye publicó avisos indicando que había reportado vulnerabilidades a Microsoft, pero sin detalles técnicos, junto con un contador visible que mostraba cuántos días llevaba Microsoft sin publicar parche.

Algunas vulnerabilidades superaron los 200 días sin parche. eEye argumentó que la transparencia sobre el plazo, sin revelar detalles técnicos, era una forma legítima de presión pública. Microsoft lo consideró irresponsable porque señalaba la existencia de fallos sin parche. Este caso ilustra la tensión fundamental: ¿quién define qué es "responsable"?

Coordinated Vulnerability Disclosure: el estándar moderno

El proceso CVD

En 2010, Microsoft propuso reemplazar el término "responsible disclosure" por "coordinated vulnerability disclosure" (CVD), argumentando que el proceso no es una cuestión de responsabilidad moral sino de coordinación práctica. El término fue adoptado por CERT/CC, ISO (ISO/IEC 29147:2018) y la mayoría de la industria.

El proceso estándar de CVD incluye:

1. Descubrimiento. El investigador descubre la vulnerabilidad mediante análisis de código, fuzzing, reversing u otras técnicas de investigación.

2. Reporte al vendedor. El investigador contacta al vendedor a través de su canal de reporte de seguridad ([email protected], formulario web, programa de bug bounty). El reporte incluye descripción técnica, prueba de concepto, análisis de impacto y pasos para reproducir.

3. Acuse de recibo. El vendedor confirma la recepción del reporte, idealmente en 24 a 72 horas. Asigna un identificador interno y un contacto de seguimiento.

4. Desarrollo del parche. El vendedor desarrolla, prueba e integra el parche en su ciclo de releases. Puede negociar el plazo con el investigador si necesita más tiempo.

5. Publicación coordinada. En la fecha acordada, el vendedor publica el parche y el advisory de seguridad. El investigador publica su write-up técnico simultáneamente o poco después. Si la CVE está asignada, el registro NVD se actualiza con los detalles.

6. Seguimiento. El investigador verifica que el parche resuelve efectivamente la vulnerabilidad y no introduce regresiones.

El rol de los coordinadores

Cuando una vulnerabilidad afecta a múltiples productos o vendedores (ej: un fallo en una librería como OpenSSL, o en un protocolo estándar), la coordinación se complica. Aquí entran organizaciones como:

• CERT/CC (Carnegie Mellon University): coordinador principal para vulnerabilidades multi-vendedor. Plazo base de 45 días.
• CERTs nacionales (INCIBE-CERT en España, CERT-FR en Francia, JPCERT/CC en Japón): coordinan a nivel nacional y regional.
• Plataformas de bug bounty (HackerOne, Bugcrowd): actúan como intermediarios en sus programas.

Google Project Zero: el estándar de facto

La política de 90 días (2014)

Cuando Google lanzó Project Zero en 2014, estableció una política que se convertiría en el estándar de facto: 90 días desde la notificación al vendedor. Si el vendedor no publica parche en 90 días, Project Zero publica los detalles técnicos completos automáticamente, sin excepciones.

La política era deliberadamente estricta. Google argumentó que 90 días son suficientes para que cualquier organización seria desarrolle y publique un parche. Plazos más largos solo incentivan la lentitud.

Evolución: 90+30 (2021)

En 2021, Project Zero refinó su política con el modelo 90+30:

• Si el vendedor publica parche dentro de los 90 días, Project Zero espera 30 días adicionales antes de publicar detalles. Esto da tiempo a los usuarios para aplicar el parche.
• Si no hay parche a los 90 días, se publican los detalles inmediatamente.
• Si la vulnerabilidad se está explotando activamente (zero-day in the wild), el plazo se reduce a 7 días.

Transparencia de reportes (2025)

En julio de 2025, Project Zero añadió una capa de transparencia: dentro de una semana de reportar una vulnerabilidad a un vendedor, publica el hecho de que el reporte se ha realizado, incluyendo el vendedor, el producto afectado, la fecha de reporte y la fecha límite de los 90 días. Sin detalles técnicos, pero con visibilidad sobre el proceso.

Casos memorables de Project Zero

Apple. La relación de Project Zero con Apple ha sido históricamente tensa. Apple opera con ciclos de release más lentos que otros vendedores y ha expresado desacuerdo público con la rigidez del plazo de 90 días. En múltiples ocasiones, Project Zero ha publicado detalles de vulnerabilidades en iOS y macOS antes de que Apple tuviera un parche disponible.

Microsoft. Project Zero ha publicado detalles de vulnerabilidades de Windows fuera de plazo en varias ocasiones. Microsoft argumentó que la complejidad de su ecosistema (miles de millones de dispositivos, múltiples versiones de Windows) requiere plazos más flexibles. Project Zero mantuvo su posición.

Cuando el disclosure sale mal

PrintNightmare (2021)

Uno de los ejemplos más notorios de disclosure problemático. CVE-2021-34527, una vulnerabilidad crítica en el servicio de impresión de Windows (Print Spooler), fue divulgada accidentalmente. Los investigadores publicaron un PoC completo en GitHub creyendo que Microsoft ya había parcheado la vulnerabilidad con una actualización previa. No era el caso: la actualización anterior solo corregía un CVE diferente (CVE-2021-1675).

El resultado fue un exploit público para una vulnerabilidad sin parche en virtualmente todos los Windows del mundo. Microsoft tuvo que desarrollar un parche de emergencia mientras los atacantes incorporaban el exploit en ransomware y herramientas de post-explotación. El caso ilustra la importancia de verificar que el parche realmente corrige la vulnerabilidad reportada antes de publicar detalles.

SolarWinds y el disclosure en contexto de espionaje estatal

El compromiso de SolarWinds Orion (descubierto en diciembre de 2020) planteó un dilema diferente. La campaña, atribuida al SVR ruso (APT29), comprometió la cadena de suministro de software de una herramienta usada por miles de organizaciones gubernamentales y privadas. El disclosure fue complejo porque:

1. Múltiples agencias gubernamentales estaban comprometidas.
2. Revelar detalles técnicos podía alertar a los atacantes de que habían sido detectados.
3. La remediación requería una respuesta coordinada masiva.

FireEye (que descubrió el compromiso) y las agencias gubernamentales tuvieron que equilibrar la necesidad de informar a las víctimas con la necesidad de no alertar prematuramente a los atacantes.

El mercado en la sombra: zero-day brokers

En paralelo al proceso legítimo de disclosure, existe un mercado donde la no publicación tiene valor económico. Los zero-day brokers compran vulnerabilidades sin parche a investigadores y las venden a gobiernos, agencias de inteligencia y, en algunos casos, a actores ofensivos.

Empresas como Zerodium publican abiertamente sus tablas de precios:

Tipo de vulnerabilidad	Precio Zerodium (hasta)
iPhone full chain (zero-click)	2.500.000 USD
Android full chain (zero-click)	2.500.000 USD
Windows RCE (zero-click)	1.000.000 USD
Chrome RCE + sandbox escape	500.000 USD
WhatsApp RCE (zero-click)	1.500.000 USD

Estos precios crean un incentivo económico directo para no reportar vulnerabilidades al vendedor. Un investigador que descubre un zero-day en iPhone tiene que decidir entre reportarlo a Apple (que paga hasta 2 millones USD a través de su Security Bounty) o venderlo a un broker (que paga cifras similares o superiores, sin las restricciones de un programa de bug bounty).

Riesgo legal para investigadores

Computer Fraud and Abuse Act (CFAA) en Estados Unidos

El CFAA, aprobado en 1986, criminaliza el acceso no autorizado a sistemas informáticos. Su lenguaje amplio ha sido usado para amenazar a investigadores de seguridad que descubren vulnerabilidades sin autorización explícita del propietario del sistema. Casos notables:

• Aaron Swartz (2011). Acusado bajo el CFAA por descargar artículos académicos de JSTOR. Aunque no era investigación de seguridad, el caso demostró el alcance punitivo de la ley.
• Marcus Hutchins (2017). El investigador que detuvo WannaCry fue posteriormente acusado por herramientas de hacking desarrolladas años antes. Aunque el caso no era estrictamente de disclosure, ilustró los riesgos legales de la investigación de seguridad.

La Cyber Resilience Act (CRA) en la Unión Europea

En 2024, la UE aprobó la Cyber Resilience Act, que incluye disposiciones relevantes para la investigación de seguridad. La CRA:

1. Reconoce explícitamente el derecho a investigar vulnerabilidades en productos cubiertos por la regulación.
2. Obliga a los fabricantes a establecer procesos de recepción y gestión de reportes de vulnerabilidades.
3. Requiere que las vulnerabilidades explotadas activamente se reporten a ENISA (la agencia de ciberseguridad de la UE).

Sin embargo, la CRA no establece un safe harbor universal para investigadores, dejando la protección legal dependiente de la legislación nacional de cada estado miembro.

Políticas de safe harbor

Cada vez más organizaciones publican políticas de safe harbor (puerto seguro) que ofrecen protección legal explícita a los investigadores que:

1. Actúan de buena fe.
2. No extraen, eliminan ni modifican datos de usuarios.
3. No causan interrupción de servicios.
4. Reportan la vulnerabilidad al vendedor antes de publicarla.
5. No utilizan la vulnerabilidad para obtener acceso no autorizado más allá de lo necesario para demostrar el fallo.

El Departamento de Justicia de Estados Unidos publicó en 2022 directrices que desaconsejan el procesamiento de investigadores de seguridad que actúen de buena fe, pero las directrices no tienen fuerza de ley.

Disclosure en la era moderna: tendencias actuales

Disclosure acelerado por IA

La aparición de herramientas de IA para descubrimiento de vulnerabilidades (fuzzing asistido por LLMs, análisis estático automatizado) está acelerando la tasa de descubrimiento. Esto pone presión adicional sobre los vendedores para reducir sus tiempos de respuesta.

Regulación creciente

La tendencia global es hacia la regulación del proceso de disclosure. La CRA europea, la directiva NIS2 y las regulaciones sectoriales (DORA para finanzas, la directiva de equipos de radio) establecen obligaciones tanto para vendedores (mantener canales de reporte, publicar parches a tiempo) como para organizaciones que usan el software (parchear dentro de plazos regulatorios).

Bug bounties como canal preferido

Los programas de bug bounty se han convertido en el canal preferido para el disclosure, ofreciendo recompensas económicas, procesos estructurados y protección legal implícita. Más de 1.950 programas activos solo en HackerOne, con pagos acumulados de cientos de millones de dólares, demuestran que la industria ha encontrado un equilibrio económico entre la investigación legítima y la seguridad del software.

Mejores prácticas para investigadores

Si descubres una vulnerabilidad, estos son los pasos recomendados:

1. Documenta todo. Capturas de pantalla, logs, pasos para reproducir. La documentación es tu protección legal.
2. Busca el canal oficial. La mayoría de empresas tienen un security.txt (RFC 9116), una dirección [email protected] o un programa de bug bounty.
3. Establece un plazo. Comunica al vendedor que publicarás los detalles en 90 días si no hay parche. Esto no es una amenaza: es el estándar de la industria.
4. No extraigas datos. Demuestra la vulnerabilidad con la mínima intrusión posible. Si puedes leer el primer registro de una base de datos para demostrar SQL injection, no descargues la base completa.
5. Solicita CVE. Pide un identificador CVE a MITRE o a un CNA (CVE Numbering Authority). Esto garantiza que la vulnerabilidad queda registrada formalmente.
6. Publica un write-up. Después del parche, publica un análisis técnico. Esto tiene valor educativo para la comunidad y contribuye a tu reputación profesional.

Conclusión: un equilibrio imperfecto pero funcional

No existe un consenso absoluto sobre el proceso ideal de disclosure. El full disclosure puro puede causar daño a usuarios desprotegidos. La confidencialidad indefinida protege a vendedores negligentes. El modelo de coordinated disclosure con plazos de 90 días representa un compromiso pragmático: presión suficiente para que los vendedores actúen, pero tiempo suficiente para que desarrollen parches de calidad.

Lo que sí es claro es que la transparencia ha mejorado drásticamente la seguridad del software. Antes de Bugtraq, los vendedores podían ignorar vulnerabilidades durante años. Hoy, con plazos estrictos, bug bounties, regulación y una comunidad de investigadores activa, los fallos se parchean más rápido que nunca. El sistema no es perfecto, pero funciona mejor que cualquier alternativa probada.