Cómo crear un programa de divulgación de vulnerabilidades en 2026

Un programa de divulgación de vulnerabilidades (VDP) es un proceso estructurado que permite a investigadores de seguridad externos reportar fallos en tu producto de forma segura y legal. A diferencia de un programa de bug bounty, que paga por cada vulnerabilidad encontrada, un VDP establece un canal claro para recibir reportes sin exigir una recompensa económica. Toda empresa con un producto expuesto a internet necesita uno. La Agencia de Ciberseguridad e Infraestructura de EE. UU. (CISA) hizo obligatorios los VDP para agencias federales en 2020 mediante la Binding Operational Directive 20-01, y el sector privado ha seguido rápidamente.

Por qué tu startup necesita un VDP ahora

Los investigadores de seguridad van a encontrar vulnerabilidades en tu producto, tengas un VDP o no. La pregunta es qué pasa después.

Sin un canal de reporte, un investigador que encuentra una inyección SQL en tu proceso de checkout tiene tres opciones: enviar un correo a tu dirección de soporte genérica y esperar que alguien técnico lo lea, publicarlo en redes sociales, o venderlo. Ninguna es buena para ti. Las vulnerabilidades en aplicaciones web siguen siendo omnipresentes, como documenta el Top Ten de OWASP que recoge los riesgos de seguridad más críticos para las organizaciones. Una sola vulnerabilidad no reportada puede convertirse en una brecha de datos que le cueste a tu empresa su reputación y sus clientes.

Los números son contundentes. Según el informe 2024 Cost of a Data Breach de IBM, el coste medio de una brecha de datos alcanzó los 4,88 millones de dólares a nivel global. Para las startups, una brecha de esa magnitud suele ser fatal. Mientras tanto, configurar un VDP no cuesta prácticamente nada. Necesitas un documento de política, un canal de recepción seguro y alguien para clasificar los reportes. Compáralo con contratar una firma de pruebas de penetración, que cuesta entre 15.000 y 50.000 dólares por proyecto según las estimaciones del SANS Institute.

La presión regulatoria también se acelera. La Directiva NIS2 de la UE, vigente desde octubre de 2024, exige que las organizaciones que operan en sectores críticos implementen la divulgación coordinada de vulnerabilidades. Las normas de divulgación de ciberseguridad de la SEC de EE. UU. de 2023 exigen a las empresas cotizadas reportar incidentes materiales en un plazo de cuatro días hábiles. Tener un VDP es la infraestructura mínima para cumplir con estas obligaciones.

VDP vs. bug bounty: ¿cuál primero?

Un VDP es la base. Un bug bounty añade una capa de incentivo financiero encima. Empezar con un bug bounty antes de tener el proceso de triaje para gestionar reportes es un error frecuente y costoso.

Característica	Programa de divulgación de vulnerabilidades	Programa de bug bounty
Coste	Gratis (sin pagos requeridos)	500-50.000+ $ por reporte válido
Alcance	Todas las vulnerabilidades	Alcance definido con exclusiones
Investigadores	Cualquiera	Atrae cazadores experimentados
Protección legal	Esencial	Esencial
Carga de triaje	Moderada	Alta (mayor volumen)
Ideal para	Cualquier empresa, desde el día uno	Empresas con equipos de seguridad maduros

Según el informe 2024 Hacker-Powered Security de HackerOne, el 77 % de las organizaciones con programas de bug bounty empezaron primero con un VDP. Construye el proceso antes de añadir el presupuesto.

Qué debe incluir una política VDP

Tu política VDP es un documento legal, una herramienta de comunicación y un conjunto de compromisos operativos. Debe cubrir cinco áreas de forma clara.

Alcance: qué pueden probar los investigadores

Define exactamente qué activos están dentro del alcance. Sé específico con dominios, rangos de IP, aplicaciones móviles y APIs. La ambigüedad aquí crea problemas en ambas direcciones: los investigadores pierden tiempo en activos fuera del alcance, y tú recibes reportes sobre los que no puedes actuar.

Una buena definición de alcance tiene este aspecto:

• Dentro del alcance: *.tuempresa.com, app iOS (App Store), app Android (Google Play), API pública en api.tuempresa.com
• Fuera del alcance: Servicios de terceros (Stripe, Intercom), seguridad física, ingeniería social contra empleados

Safe harbor: protección legal para investigadores

Esta es la sección más importante de tu política. Sin un lenguaje claro de safe harbor, los investigadores no te reportarán nada. Temerán acciones legales bajo el Computer Fraud and Abuse Act (CFAA) en EE. UU. o leyes equivalentes en otras jurisdicciones.

Las directrices CFAA del Departamento de Justicia de EE. UU. de 2022 establecen explícitamente que “la investigación de seguridad de buena fe no debería ser objeto de cargos.” Tu política debe reflejar este lenguaje. Una cláusula mínima de safe harbor incluye:

1. El compromiso de no emprender acciones legales contra investigadores que sigan la política
2. El compromiso de no invocar el CFAA ni el DMCA por investigación de buena fe
3. La declaración de que colaborarás con los investigadores si terceros inician acciones legales
4. El reconocimiento de que la investigación realizada dentro de la política está autorizada

Requisitos de reporte: qué necesitas de los investigadores

Indica a los investigadores exactamente qué debe contener su reporte. Una plantilla ahorra tiempo a ambas partes:

• Tipo de vulnerabilidad (ej.: XSS, SSRF, control de acceso deficiente)
• URL o endpoint afectado
• Pasos para reproducir (específicos, numerados)
• Evaluación del impacto (qué datos quedan expuestos, qué acceso se obtiene)
• Capturas de pantalla o prueba de concepto (vídeo preferible para cadenas complejas)
• Datos de contacto del investigador (para seguimiento)

Compromisos de respuesta: tus SLAs

Los investigadores han sido condicionados por años de ser ignorados. Según los datos de HackerOne, la mediana del tiempo hasta la primera respuesta en todos los programas es de 8 horas, aunque el cuartil superior responde en menos de 1 hora. Tus SLAs señalan si te tomas la seguridad en serio.

Define y publica estos plazos:

• Acuse de recibo: dentro de 2 días hábiles
• Decisión de triaje: dentro de 5 días hábiles
• Actualización de estado: al menos cada 14 días hasta la resolución
• Plazo de corrección: según gravedad (crítica: 7 días, alta: 30 días, media: 90 días)

Calendario de divulgación: coordinada vs. completa

La mayoría de los VDP usan divulgación coordinada: el investigador acepta mantener silencio mientras corriges el problema, y tú te comprometes a corregirlo dentro de un plazo definido (normalmente 90 días, alineado con el estándar de Google Project Zero). Pasado ese plazo, el investigador puede publicar.

Sé explícito al respecto. Los investigadores respetan a las organizaciones que se comprometen con plazos. Desconfían de las que piden silencio indefinido.

Cómo redactar tu archivo security.txt

El estándar security.txt (RFC 9116) le da a tu VDP un punto de entrada legible por máquinas. Es un archivo de texto plano en /.well-known/security.txt que indica a herramientas automatizadas e investigadores dónde reportar vulnerabilidades.

Un security.txt completo incluye:

Contact: mailto:[email protected]
Contact: https://tuempresa.com/security/report
Expires: 2027-03-15T00:00:00.000Z
Encryption: https://tuempresa.com/.well-known/pgp-key.txt
Policy: https://tuempresa.com/security/policy
Preferred-Languages: es, en
Canonical: https://tuempresa.com/.well-known/security.txt

El campo Expires es obligatorio en la RFC 9116. Configúralo a un máximo de un año y programa un recordatorio recurrente para actualizarlo. Un security.txt expirado señala abandono, lo cual es peor que no tener ninguno.

Según datos de securitytxt.org, la adopción entre el Top 1 Millón de Alexa ha crecido de menos del 2 % en 2022 a aproximadamente el 8 % en 2025. Entre las empresas que han sufrido una divulgación pública de brecha, la adopción supera el 30 %. No esperes a una brecha para publicar el tuyo.

Paso a paso: lanza tu VDP en una semana

No necesitas meses de planificación para lanzar un VDP. Aquí tienes un calendario concreto para una startup de 5 a 50 empleados.

Día 1-2: Redactar la política

Comienza con las plantillas comunitarias de disclose.io. Su lenguaje de safe harbor ha sido revisado por equipos legales de organizaciones como la EFF, Dropbox y Bugcrowd. Personaliza la sección de alcance para tus activos y que tu asesor legal lo revise (la mayoría de abogados de startups pueden hacerlo en 24 horas).

Día 3: Configurar el canal de recepción

Necesitas una vía segura y fiable para recibir reportes. Las opciones:

• Correo electrónico dedicado ([email protected]) con cifrado PGP
• Formulario web en tu página de seguridad con TLS y controles de acceso
• Plataforma (HackerOne, Bugcrowd, Intigriti) para recepción y triaje gestionado

Un correo dedicado funciona para la mayoría de las startups. Añade una clave PGP para que los investigadores puedan cifrar los detalles sensibles. Si esperas más de cinco reportes al mes, una plataforma te ahorrará un tiempo considerable de triaje.

Día 4: Publicar security.txt y la página de política

Crea tu archivo security.txt y publícalo en /.well-known/security.txt. Crea una página /security en tu web con la política completa, el alcance y las instrucciones de reporte.

Día 5: Construir el workflow de triaje

Define quién recibe los reportes, cómo se priorizan y cómo se hace seguimiento de las correcciones. Como mínimo:

1. Recepción: Los reportes de seguridad llegan por un canal dedicado (correo, plataforma o formulario)
2. Triaje: Un ingeniero evalúa la gravedad en 2 días hábiles usando CVSS 4.0
3. Seguimiento: Crea un ticket interno en tu gestor de incidencias (no pongas detalles de vulnerabilidades en issues públicas de GitHub)
4. Corrección: Asigna al equipo correspondiente según el componente afectado
5. Comunicación: Mantén al investigador informado en cada etapa
6. Cierre: Confirma la corrección con el investigador, ofrece mención en tu hall of fame

Día 6-7: Probar y anunciar

Envía un reporte de prueba a través de tu propio proceso. Verifica que el correo de acuse de recibo funcione, que el workflow de triaje se active y que las plantillas de respuesta sean claras. Luego anuncia tu VDP:

• Añade un enlace en el pie de página de tu web
• Publica un artículo en tu blog técnico
• Notifica a las comunidades de seguridad relevantes

Errores comunes que destruyen la credibilidad del VDP

Ignorar los reportes

La forma más rápida de destruir la reputación de tu VDP es no responder. Los investigadores hablan entre ellos. Si tres personas reportan problemas y no reciben respuesta, tu programa está efectivamente muerto. Los datos de HackerOne muestran que los programas con tiempos de respuesta superiores a 7 días reciben un 40 % menos de envíos en el trimestre siguiente.

Alcance demasiado estrecho

Limitar el alcance a una sola página de marketing cuando tu superficie de ataque real incluye APIs, apps móviles e integraciones de terceros les dice a los investigadores que no vas en serio. Si no estás preparado para corregir problemas en toda tu superficie, sé honesto en la política, pero planifica ampliarlo.

Amenazar a los investigadores

Esto todavía ocurre. En 2023, una gran aerolínea amenazó con acciones legales a un investigador que había reportado una vulnerabilidad a través de su canal oficial. El daño reputacional les costó mucho más que lo que habría costado la corrección de la vulnerabilidad. Tu lenguaje de safe harbor existe para prevenir esto. Asegúrate de que tu equipo legal y la dirección lo entienden y lo respaldan.

Sin retroalimentación

Los investigadores quieren saber que su reporte importó. Envíales el identificador CVE si se asigna uno. Comunícales cuándo se despliega la corrección. Ofrece mención en tus avisos de seguridad. No cuesta nada y construye una relación que genera más reportes de calidad.

Evaluación de gravedad con CVSS 4.0

El Common Vulnerability Scoring System versión 4.0, publicado por FIRST.org en noviembre de 2023, es el estándar actual para evaluar la gravedad de las vulnerabilidades. CVSS 4.0 introdujo mejoras significativas respecto a la versión 3.1, incluyendo métricas suplementarias para automatización, recuperación y densidad de valor.

Usa CVSS para crear niveles de SLA consistentes:

Puntuación CVSS 4.0	Gravedad	SLA de respuesta	SLA de corrección
9,0-10,0	Crítica	4 horas	7 días
7,0-8,9	Alta	24 horas	30 días
4,0-6,9	Media	2 días hábiles	90 días
0,1-3,9	Baja	5 días hábiles	Mejor esfuerzo

No inventes tu propia escala de gravedad. CVSS es un estándar imperfecto, pero es un lenguaje compartido entre tu equipo y la comunidad de investigadores. Desviarte de él genera confusión y disputas.

De VDP a bug bounty

Una vez que tu VDP lleve funcionando 3 a 6 meses y tengas un workflow de triaje fiable, puedes considerar añadir recompensas económicas.

Cuándo añadir bounties

Estás preparado cuando:

• Tu tiempo medio de primera respuesta es inferior a 24 horas
• Has corregido al menos el 80 % de las vulnerabilidades reportadas dentro de tus SLAs publicados
• Tienes un contacto de seguridad dedicado (no necesita ser a tiempo completo)
• Tu equipo de ingeniería tiene un proceso para priorizar correcciones de seguridad junto al trabajo de producto

Establecer los importes de las recompensas

Los importes de las bounties deben reflejar el impacto real de la vulnerabilidad, no una tarifa fija. Los datos de 2024 de HackerOne muestran los pagos medianos en todas las industrias:

• Crítica: 3.000-15.000 $ (ejecución remota de código, bypass de autenticación)
• Alta: 1.000-5.000 $ (XSS almacenado, IDOR con exposición de PII)
• Media: 250-1.000 $ (XSS reflejado, divulgación de información)
• Baja: 50-250 $ (redirección abierta, mensajes de error detallados)

Para startups, empezar en el extremo inferior de estos rangos está bien. Los investigadores valoran más la rapidez de respuesta y el respeto que los pagos máximos. Un programa que paga 500 $ y responde en 4 horas atraerá mejor talento que uno que paga 5.000 $ e ignora los reportes durante semanas.

Marcos de cumplimiento que exigen un VDP

Un VDP no es solo buena práctica. Varios marcos de cumplimiento lo exigen explícitamente.

SOC 2 Type II: Aunque SOC 2 no exige un VDP por nombre, los Criterios Comunes relacionados con la evaluación de riesgos (CC3.2) y la comunicación (CC2.3) son significativamente más fáciles de cumplir con un VDP documentado. Los auditores preguntan cada vez más por evidencia de un canal externo de recepción de vulnerabilidades.

ISO 27001:2022: El control A.8.8 (Gestión de vulnerabilidades técnicas) exige a las organizaciones “establecer e implementar reglas para la divulgación de vulnerabilidades.” Un VDP cumple directamente este control.

PCI DSS 4.0: El requisito 6.3.1 exige que las organizaciones identifiquen y gestionen vulnerabilidades de seguridad, incluyendo fuentes externas. Un VDP demuestra el cumplimiento del requisito de “fuente externa.”

NIST Cybersecurity Framework 2.0: La función Identificar (ID.RA-01) requiere que las “vulnerabilidades en activos” sean “identificadas, validadas y registradas,” incluyendo explícitamente el descubrimiento externo. La nueva función Gobernar (GV.SC-05) añade la gestión de riesgos de la cadena de suministro, donde los VDP juegan un papel cada vez más importante.

Directiva NIS2 (UE): El artículo 12 exige a los Estados miembros de la UE establecer políticas de divulgación coordinada de vulnerabilidades. Las organizaciones en sectores esenciales e importantes deben participar.

Si tu startup atiende a clientes empresariales, un VDP aparece frecuentemente en los cuestionarios de seguridad. Según una encuesta de Whistic de 2024, el 64 % de los compradores empresariales incluyen la gestión de vulnerabilidades en las evaluaciones de seguridad de proveedores. Tener un VDP publicado acorta tu ciclo de ventas al dar a los equipos de compras una respuesta inmediata.

Hall of fame: reconocer a los investigadores

Un hall of fame público no cuesta nada de mantener y genera una buena voluntad significativa con la comunidad de investigación en seguridad. Reconoce a los investigadores que han divulgado vulnerabilidades de forma responsable e incentiva futuros reportes sin requerir recompensas económicas.

Tu hall of fame debe incluir:

• Nombre o identificador del investigador (según su preferencia de crédito)
• Fecha de la divulgación
• Categoría general de la vulnerabilidad (sin revelar detalles explotables)

No publiques detalles completos de la vulnerabilidad, endpoints afectados o pasos de reproducción en tu hall of fame. Limítalo a nombres y fechas. El aviso de seguridad detallado (si se publica) debe ser un documento separado, publicado después de que la corrección haya sido desplegada y verificada.

Algunos investigadores construyen su reputación profesional a través de créditos en halls of fame. Para consultores independientes y estudiantes, un reconocimiento público de tu empresa puede tener más valor que una pequeña recompensa. Trátalo con la seriedad que merece.

Cómo Kit gestiona la divulgación de vulnerabilidades

Kit incluye un módulo CSIRT (Computer Security Incident Response Team) integrado que trata la divulgación de vulnerabilidades como un workflow de primera clase, no como un complemento improvisado sobre un sistema de tickets.

El módulo incluye un portal de seguridad personalizable al que los investigadores acceden a través de tu dominio. Publicas tu política VDP, tu alcance y tus directrices de reporte directamente desde Kit. Los investigadores envían reportes a través de un formulario estructurado que recoge exactamente la información que tu equipo de triaje necesita: tipo de vulnerabilidad, activos afectados, pasos de reproducción y evaluación del impacto. Se acabó el parseo de correos de texto libre o perder reportes en una bandeja de entrada compartida.

Cada reporte fluye por un pipeline de triaje definido con SLAs configurables. Kit rastrea automáticamente el tiempo hasta la primera respuesta, hasta el triaje y hasta la resolución. Cuando una fecha límite se acerca, el miembro del equipo asignado recibe una notificación. Cuando se supera, las reglas de escalado se activan. Es el mismo patrón de cumplimiento de SLAs que usan plataformas dedicadas como HackerOne, integrado en la misma herramienta que tu equipo ya usa para contratación.

Kit genera y mantiene tu archivo security.txt automáticamente, incluyendo el campo obligatorio Expires con una comprobación recurrente que te avisa antes de que expire. El portal de seguridad soporta dominios personalizados, para que los investigadores interactúen con security.tuempresa.com en lugar de una plataforma de terceros.

El módulo también incluye un hall of fame público, integración con Slack para notificaciones en tiempo real de reportes, y comunicación con investigadores directamente a través del portal. Los desembolsos de recompensas de bug bounty se rastrean con un registro completo, proporcionándote documentación lista para auditoría en las revisiones SOC 2 e ISO 27001.

Para startups que necesitan tanto infraestructura de contratación como de seguridad, Kit elimina la necesidad de gestionar plataformas separadas. Tu módulo CSIRT funciona junto a tu ATS, usando las mismas cuentas de equipo, el mismo espacio de trabajo de Slack y la misma facturación. Eso significa un proveedor menos, un cuestionario de seguridad menos que rellenar y un login menos para tu equipo.

Checklist: lanza tu VDP esta semana

Usa esta checklist para seguir tu progreso. Cada punto puede completarlo un solo ingeniero en una semana.

1. Redacta tu política VDP usando las plantillas de disclose.io
2. Define tu alcance (dominios, APIs, apps móviles)
3. Redacta el lenguaje de safe harbor y que lo revise tu asesor legal
4. Configura un canal de recepción seguro (correo con PGP, formulario web o plataforma)
5. Crea tu archivo security.txt en /.well-known/security.txt
6. Publica tu página de política en /security o /security/policy
7. Define niveles de gravedad y SLAs de respuesta con CVSS 4.0
8. Construye el workflow de triaje interno (quién recibe, quién clasifica, quién corrige)
9. Crea plantillas de respuesta (acuse de recibo, decisión de triaje, actualización de estado, resolución)
10. Configura una página pública de hall of fame
11. Envía un reporte de prueba a través de tu propio proceso
12. Anuncia tu VDP (pie de página web, artículo de blog, comunidades de seguridad)

Un VDP no es un proyecto puntual. Es un compromiso continuo con tus usuarios de que te tomas su seguridad en serio. La configuración lleva una semana. La credibilidad que construye lleva años. Empieza ahora, mientras todavía es una ventaja competitiva y no una obligación regulatoria que estás intentando cumplir a toda prisa.