Vulnerability Disclosure Program: lo creamos, lo gestionamos y lo mantenemos

Un VDP es el canal por el que alguien de fuera te avisa de un fallo antes de que lo use un atacante. Lo diseñamos y publicamos, respondemos a cada reporte que entra con plazos comprometidos y revisamos el programa cada trimestre para que siga cubriendo lo que tienes hoy. Sin equipo interno dedicado y con la evidencia documental que piden NIS2 y el Cyber Resilience Act.

Última actualización: octubre de 2026

24 h · 72 h · 14 d — Plazos del CRA para notificar una vulnerabilidad explotada: alerta, notificación e informe final (art. 14)
5 años — Periodo mínimo en el que el CRA obliga al fabricante a gestionar vulnerabilidades y publicar actualizaciones
ISO 29147 + 30111 — Estándares de divulgación y de tratamiento interno con los que montamos el proceso
2-4 semanas — De la primera reunión al canal publicado en /.well-known/security.txt y la política en vivo

Un canal de divulgación sin nadie detrás es peor que no tenerlo

Publicar una política de divulgación responsable es la parte fácil. Lo difícil empieza después, y falla casi siempre por los mismos tres sitios: el reporte entra en un buzón que nadie vigila y se descubre semanas más tarde; llega un acuse automático pero nunca una respuesta real, así que el investigador se cansa y publica el fallo por su cuenta; o el reporte sí se lee, pero nadie sabe si es grave, si es duplicado o si hay que notificarlo a una autoridad, y la decisión se queda esperando.

El coste de esos tres fallos no es solo técnico. Quien publica un canal de divulgación asume un compromiso público, y una gestión tardía se lee desde fuera como desinterés por la seguridad. Además, desde que NIS2 y el Cyber Resilience Act exigen gestionar y divulgar vulnerabilidades, lo que antes era buena práctica ahora deja rastro documental: si no hay registro de qué entró, cuándo se respondió y qué se corrigió, no hay nada que enseñar en una auditoría.

Nosotros nos ocupamos de la parte que falla. Diseñamos el programa, abrimos el canal, respondemos a cada reporte con plazos acordados y dejamos el registro completo detrás.

Qué incluye el servicio, fase por fase

Diagnóstico del punto de partida: reportes que ya os llegan, canales abiertos y obligaciones normativas que os aplican
Redacción de la política de divulgación responsable con alcance, reglas, qué no se debe probar y cláusula de safe harbor
Implantación del canal de entrada: formulario cifrado, buzón con PGP o plataforma especializada (HackerOne Response, Bugcrowd, Intigriti)
Publicación en los sitios donde los investigadores la buscan: /.well-known/security.txt (RFC 9116), página de seguridad y política pública
Acuerdo de SLAs de acuse, primera valoración y resolución, con escalada específica para hallazgos críticos
Gestión de todos los reportes entrantes: recepción, acuse, triage técnico, duplicados y cierre
Comunicación con los investigadores en tu nombre, en español y en inglés
Priorización de lo validado con CVSS 4.0 y EPSS, para que tu equipo corrija por riesgo real y no por orden de llegada
Coordinación con tu equipo técnico durante la remediación y verificación del arreglo antes de cerrar el caso
Gestión de la divulgación coordinada (CVD, ISO/IEC 29147) y petición de CVE cuando el investigador quiere publicar
Apoyo en la notificación regulatoria: qué entra en los plazos del CRA y qué hay que llevar al CSIRT que corresponda
Revisión trimestral del programa: alcance, SLAs cumplidos, política y volumen, con informe mensual de actividad

Cómo lo implantamos

Diagnóstico y diseño de la política: Analizamos el entorno, acordamos qué entra y qué no entra en el alcance, redactamos la política de divulgación y fijamos los SLAs de respuesta. Seguimos ISO/IEC 29147 para la divulgación e ISO/IEC 30111 para el tratamiento interno del reporte.
Implantación y publicación del canal: Configuramos el canal de recepción y lo publicamos donde se busca: security.txt en /.well-known/, página de seguridad y política pública. Probamos el circuito completo con un reporte de prueba antes de anunciarlo.
Operación del triage: Cada reporte pasa por el mismo proceso: acuse al investigador, reproducción técnica, descarte de duplicados y falsos positivos, severidad con CVSS 4.0 y EPSS, y entrega al equipo de remediación con los pasos para corregirlo.
Divulgación coordinada: Si el investigador quiere publicar, acordamos el calendario, preparamos la comunicación pública, gestionamos la petición de CVE y nos aseguramos de que el parche esté disponible antes de que salgan los detalles.
Mantenimiento del programa: Revisamos cada trimestre el alcance frente a lo que habéis desplegado desde la última vez, los SLAs que se han cumplido y los que no, y la política si ha cambiado algo relevante en normativa o en el producto.

Quién hace qué, y en cuánto tiempo

Las tres fases del servicio con el responsable de cada paso y el plazo comprometido cuando lo hay. Lo que no tiene reloj es porque se acuerda con vuestro equipo, no porque no tenga fecha.

Creamos

De no tener canal a tener un programa publicado y probado, en dos a cuatro semanas.

Diagnóstico de partida (QuantumSec · Semana 1): Revisamos qué reportes os llegan ya, por qué vías, y qué obligaciones de divulgación os aplican según NIS2, el CRA o vuestro sector.
Decisión de alcance (Tu equipo · Semana 1): Acordamos qué dominios, productos y versiones entran, qué queda fuera y qué pruebas no se admiten nunca (denegación de servicio, ingeniería social al personal, datos de terceros).
Redacción de la política (QuantumSec · Semana 2): Política de divulgación responsable completa: alcance, reglas de participación, qué espera el investigador a cambio, plazos y cláusula de safe harbor revisada con vuestro equipo legal.
Canal de entrada (QuantumSec · Semana 3): Montamos el canal elegido —formulario cifrado, buzón con clave PGP o plataforma especializada— y lo conectamos con nuestro flujo de triage.
Publicación y prueba (QuantumSec · Semana 4): Publicamos la política y el security.txt en /.well-known/ (RFC 9116), y enviamos un reporte de prueba de punta a punta antes de anunciar el programa.

Al cerrar esta fase: Política publicada, canal operativo, security.txt en su sitio y el circuito verificado con un reporte real de prueba.

Gestionamos

Cada reporte que entra tiene dueño, plazo y respuesta. También en agosto.

Llega el reporte (Investigador): El investigador envía el hallazgo por el canal publicado. Entra en nuestra cola, no en un buzón compartido que nadie vigila.
Acuse de recibo (QuantumSec · 24 h laborables): Respuesta real al investigador confirmando recepción, con el número de caso y el plazo en el que tendrá una primera valoración.
Triage técnico (QuantumSec · 72 h laborables): Reproducimos el fallo, descartamos duplicados y falsos positivos, y fijamos severidad con CVSS 4.0 y probabilidad de explotación con EPSS.
Escalada de lo crítico (QuantumSec · 4 h laborables): Si el impacto puede ser crítico, avisamos al responsable de seguridad por la vía de urgencia acordada, sea la hora que sea, y coordinamos la respuesta.
Remediación (Tu equipo): Entregamos el hallazgo validado con los pasos de corrección, acompañamos las dudas del equipo y verificamos el arreglo antes de cerrar el caso.
Cierre y divulgación coordinada (QuantumSec): Cerramos con el investigador. Si quiere publicar, acordamos el calendario, gestionamos la petición de CVE y preparamos la comunicación pública para después del parche.

Al cerrar esta fase: Ningún reporte sin respuesta, lo crítico escalado el mismo día y el registro completo de qué entró, qué se validó y qué se corrigió.

Mantenemos

Un programa que no se revisa envejece: el alcance deja fuera lo que desplegaste después.

Informe mensual (QuantumSec · Mensual): Volumen de reportes, tasa de validación, duplicados, tiempos de respuesta reales frente a los comprometidos y estado de cada caso abierto.
Revisión de alcance (QuantumSec · Trimestral): Repasamos qué habéis puesto en producción desde la última revisión y lo añadimos al alcance publicado, para que el programa cubra lo que de verdad está expuesto.
Ajuste de política y SLAs (QuantumSec · Trimestral): Si los plazos no se están cumpliendo o la normativa ha cambiado, actualizamos política, SLAs y security.txt, y lo republicamos.
Evidencia para auditoría (QuantumSec): Mantenemos el expediente que pide un auditor de NIS2, del CRA o de ISO 27001: política vigente, histórico de reportes, plazos y decisiones tomadas en cada caso.
Decisión de evolución (Tu equipo): Cuando el programa recibe más de lo que absorbe, valoramos con vosotros el salto a un bug bounty con recompensas o a un alcance por fases.

Al cerrar esta fase: Un programa al día, con alcance acorde a lo que tenéis desplegado y el expediente de cumplimiento listo para quien lo pida.

Qué te queda en casa

Política de divulgación responsable redactada, revisada y publicada
Cláusula de safe harbor con el compromiso legal frente al investigador de buena fe
Canal de recepción operativo y securizado, con el security.txt publicado según RFC 9116
Gestión completa de todos los reportes entrantes, con los SLAs acordados por escrito
Cada hallazgo validado con CVSS 4.0, EPSS y pasos concretos de corrección
Registro íntegro de las interacciones con investigadores, caso por caso
Informe mensual de actividad y revisión trimestral del programa
Expediente de cumplimiento para NIS2, el Cyber Resilience Act y auditorías ISO 27001
Procedimiento de divulgación coordinada acordado y documentado, listo para el primer caso

Para qué tipo de empresa es este servicio

Entidades esenciales o importantes sujetas a NIS2, donde la gestión y divulgación de vulnerabilidades es una de las medidas del artículo 21
Fabricantes de productos con elementos digitales afectados por el Cyber Resilience Act, que necesitan política de CVD y capacidad de notificar en 24 y 72 horas
Empresas que ya reciben reportes por LinkedIn, por el formulario de contacto o por el buzón de soporte y no tienen proceso para tratarlos
Equipos de seguridad pequeños que no pueden garantizar respuesta fuera de horario ni en vacaciones
Startups que quieren un canal de divulgación serio desde el principio, sin montar un bug bounty con recompensas
Entidades públicas y proveedores de la administración que deben acreditar un canal de notificación de vulnerabilidades
Empresas con un bug bounty activo que necesitan separar el VDP gratuito del programa con recompensas

Buzón de seguridad, VDP gestionado y bug bounty

Las tres cosas se confunden a menudo. Un buzón es una dirección de correo; un VDP es un proceso con compromisos públicos; un bug bounty añade dinero a ese proceso para atraer más investigadores.

	Buzón security@ sin proceso	VDP gestionado	Bug bounty con recompensas
Política pública con alcance y reglas	No	Sí, redactada y publicada	Sí, más tabla de recompensas
Safe harbor legal para el investigador	No	Sí	Sí
Acuse de recibo con plazo	Automático o ninguno	Respuesta real en 24 h laborables	Según plataforma o gestor
Triage técnico de cada reporte	Lo hace tu equipo cuando puede	Incluido, con CVSS 4.0 y EPSS	Incluido si el triage está gestionado
Pago al investigador	No	No: reconocimiento, no dinero	Sí, por hallazgo válido
Volumen de reportes esperado	Esporádico	Bajo y constante	Alto, con más ruido
Divulgación coordinada y petición de CVE	Sin proceso	Gestionada, ISO/IEC 29147	Gestionada
Evidencia para NIS2, CRA e ISO 27001	Lo que haya en el correo	Expediente completo	Expediente completo
Cuándo encaja	Nunca como única medida	Primer canal formal y base de cumplimiento	Cuando el VDP ya funciona y quieres más cobertura

Compara con

Preguntas frecuentes sobre VDP gestionado

¿NIS2 me obliga a tener un VDP?

NIS2 no usa la palabra "VDP", pero su artículo 21.2.e incluye la gestión y divulgación de vulnerabilidades entre las medidas que deben aplicar las entidades esenciales e importantes, y el artículo 12 monta el marco europeo de divulgación coordinada, con un CSIRT coordinador designado por cada Estado miembro y la base de datos europea de vulnerabilidades que mantiene ENISA. Para algunos tipos de entidad —proveedores de servicios en la nube, centros de datos, CDN, marketplaces, buscadores, proveedores de servicios gestionados y de confianza, entre otros— el Reglamento de Ejecución (UE) 2024/2690 detalla además el procedimiento de tratamiento y divulgación que hay que tener por escrito. La forma habitual de cumplir todo eso es, en la práctica, un VDP. Te decimos en el diagnóstico qué parte te aplica de verdad.

¿Y el Cyber Resilience Act?

El CRA es más explícito: el anexo I, parte II obliga al fabricante de un producto con elementos digitales a tener una política de divulgación coordinada de vulnerabilidades y un canal accesible para recibir reportes, además de gestionar las vulnerabilidades durante el periodo de soporte, que no puede ser inferior a cinco años. Y desde el 11 de septiembre de 2026 el artículo 14 exige notificar las vulnerabilidades activamente explotadas y los incidentes graves por la plataforma única de ENISA, con tres entregas: alerta temprana en 24 horas, notificación en 72 horas e informe final en 14 días. Sin un canal de entrada y un triage capaz de valorar un reporte en horas, esos plazos no se cumplen.

¿Cuánto tiempo tarda en estar operativo el VDP?

Entre dos y cuatro semanas: diagnóstico y alcance la primera, política la segunda, canal la tercera y publicación con prueba de punta a punta la cuarta. Si hay una auditoría o una fecha de cumplimiento encima, se puede comprimir, normalmente a costa de arrancar con un alcance más estrecho y ampliarlo después.

¿Qué diferencia hay entre un VDP y un bug bounty?

El VDP es un canal de divulgación responsable: define cómo reportar, qué entra en el alcance y qué puede esperar el investigador, sin recompensas económicas. El bug bounty añade dinero por hallazgo válido, lo que atrae a muchos más investigadores y, con ellos, mucho más volumen y mucho más ruido. El orden lógico es montar primero el VDP, comprobar que el proceso aguanta y solo entonces valorar un bug bounty. Lo comparamos a fondo en nuestra guía de bug bounty frente a VDP.

¿Qué pasa si recibimos una vulnerabilidad crítica?

Tiene su propia vía. En cuanto el triage detecta que un reporte puede tener impacto crítico, lo escalamos directamente a vuestro responsable de seguridad por el canal de urgencia acordado, sea la hora que sea, y coordinamos la respuesta desde ahí. El SLA comprometido para ese aviso es de 4 horas laborables, y en paralelo valoramos si el caso activa alguna obligación de notificación regulatoria.

¿Hace falta pagar recompensas en un VDP?

No, y es justo lo que lo distingue del bug bounty. Lo que el investigador espera a cambio es otra cosa: que alguien le responda, que le digan si su hallazgo era válido, que se corrija y que, si quiere, se le reconozca públicamente en un hall of fame o en el aviso de seguridad. Esa contrapartida no cuesta dinero, cuesta proceso, y es exactamente la parte que gestionamos.

¿Qué es el safe harbor y por qué lo necesita mi política?

Es el compromiso explícito de no emprender acciones legales contra quien reporte un fallo de buena fe y dentro del alcance publicado. Sin esa cláusula, un investigador prudente asume que avisarte puede salirle caro y elige no hacerlo, o avisar de forma anónima y sin detalle suficiente para reproducir el problema. Redactamos la cláusula y la revisamos con vuestro equipo legal antes de publicarla.

¿Quién responde a los investigadores, vosotros o nosotros?

Respondemos nosotros en tu nombre, en español y en inglés, y tu equipo queda en copia de todo. Las decisiones que afectan al negocio —aceptar un riesgo, fijar una fecha de parche, autorizar una publicación— son siempre vuestras: nosotros las preparamos con el contexto técnico ya hecho para que se puedan tomar rápido.

¿Podéis coordinar la divulgación pública de una vulnerabilidad?

Sí. Si el investigador quiere publicar su hallazgo, en un blog, en una charla o como CVE, gestionamos el proceso de divulgación coordinada siguiendo ISO/IEC 29147: acordamos el calendario con él, tramitamos la petición de CVE con la CNA que corresponda, preparamos el aviso de seguridad y verificamos que el parche está disponible antes de que salgan los detalles técnicos.