Coordinated Vulnerability Disclosure (CVD): qué es y cómo implementarlo en tu empresa

Por Kike Gandia · Co-Fundador y CEO, OSCP

El Coordinated Vulnerability Disclosure (CVD), también conocido como responsible disclosure, es el proceso mediante el cual un investigador de seguridad que descubre una vulnerabilidad la comunica al afectado antes de publicarla, y ambas partes coordinan el timeline de divulgación pública. El estándar internacional que define este proceso es la norma ISO/IEC 29147.

Por qué el CVD es preferible al full disclosure

El full disclosure consiste en publicar la vulnerabilidad de inmediato, sin coordinación previa con el afectado. Para el investigador, maximiza el impacto de su hallazgo. Para la empresa, es devastador: la vulnerabilidad se hace pública antes de que haya un parche disponible, lo que maximiza la ventana de explotación.

El CVD ofrece un equilibrio: el investigador obtiene crédito por su hallazgo y la empresa tiene tiempo para parchear antes de la publicación. El resultado es mejor para todos: el investigador construye reputación, la empresa resuelve el problema y la comunidad de seguridad accede a la información cuando el riesgo está mitigado.

Fases del proceso de CVD según ISO 29147

ISO 29147 define el proceso de CVD en las siguientes fases:

1. Recepción del reporte: el investigador notifica la vulnerabilidad al afectado a través del canal definido en el VDP.
2. Acuse de recibo: el afectado confirma la recepción y asigna un identificador al reporte.
3. Validación técnica: el afectado verifica que la vulnerabilidad es real.
4. Resolución: desarrollo y despliegue del parche.
5. Coordinación del timeline de divulgación: investigador y empresa acuerdan una fecha de publicación pública.
6. Publicación: se publica la información sobre la vulnerabilidad (CVE, advisory, blog post del investigador).

El plazo estándar de la industria es 90 días desde la notificación hasta la publicación, aunque puede variar según la complejidad de la solución.

Qué hacer cuando el investigador quiere publicar antes del parche

Si el investigador insiste en publicar antes de que el parche esté disponible, tienes varias opciones:

Comunicar el estado real: explicar por qué el parche está tardando y proponer una nueva fecha de divulgación.
Publicar un advisory propio: si la vulnerabilidad va a publicarse, es mejor que tú controles la narrativa con un advisory propio que reconozca el hallazgo.
Notificar a los CERTs: si la vulnerabilidad es grave, notificar a INCIBE-CERT o ENISA puede ayudar a gestionar la divulgación de forma más ordenada.

Lo que nunca debes hacer: amenazar legalmente al investigador que actúa de buena fe dentro de las reglas de tu VDP. Destruye la reputación del programa y desincentiva la divulgación responsable.

CVE: cuándo y cómo solicitar un identificador

Si la vulnerabilidad reportada afecta a software que distribuyes o mantienes, deberías solicitar un CVE (Common Vulnerabilities and Exposures). Un CVE es un identificador único que permite a la comunidad referenciar la vulnerabilidad de forma inequívoca.

Puedes solicitar un CVE a través de:
• MITRE CVE Program: cve.org
• CNAs (CVE Numbering Authorities): si eres fabricante de software, puedes convertirte en CNA y emitir tus propios CVEs.
• INCIBE-CERT actúa como CNA para vulnerabilidades en productos españoles.

Publicar un CVE con el crédito del investigador es una forma de reconocimiento muy valorada en la comunidad.

FAQ

¿Cuánto tiempo tengo para parchear antes de que el investigador publique?

El plazo estándar de la industria es 90 días. Google Project Zero popularizó este plazo, que después se convirtió en referencia del sector. Algunas organizaciones usan 60 o 120 días. Lo importante es que el plazo esté establecido en tu política de divulgación antes de que llegue el primer reporte.

¿Qué pasa si la vulnerabilidad afecta a un proveedor externo que no es mi software?

Si la vulnerabilidad está en software o infraestructura de terceros, tu responsabilidad es notificar al proveedor afectado y coordinar con él. Puedes actuar de intermediario entre el investigador y el proveedor, o derivar el reporte directamente al CERT correspondiente si el proveedor no tiene VDP.

¿Qué es un "safe harbor" en el contexto del VDP?

El safe harbor es la cláusula de tu política de VDP que establece que no tomarás acciones legales contra investigadores que descubran y reporten vulnerabilidades actuando dentro de las reglas del programa. Es un elemento fundamental para construir confianza con la comunidad de investigadores.