Cómo montar un programa de divulgación de vulnerabilidades (VDP) en 2026

Un programa de divulgación de vulnerabilidades (VDP) es un proceso estructurado que ofrece a los investigadores de seguridad externos un canal seguro y legal para reportar fallos en tu producto. A diferencia de un bug bounty, que paga por cada hallazgo, un VDP simplemente establece el mecanismo de recepción. 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 las agencias federales en 2020 a través de la Binding Operational Directive 20-01, y el sector privado ha seguido el ejemplo rápidamente desde entonces.

Por qué tu startup necesita un VDP antes que nada

Los investigadores de seguridad van a encontrar vulnerabilidades en tu producto, los invites o no. La única pregunta es qué pasa después.

Imagina un escenario concreto. Un investigador descubre una inyección SQL en tu API. Sin un VDP, tiene tres opciones: enviar un correo a tu dirección genérica de soporte y esperar que alguien técnico lo lea, publicarlo en redes sociales o venderlo en un foro. Ninguno de estos desenlaces te conviene. Con un VDP, el investigador tiene un camino claro para reportar el hallazgo, y tú tienes un proceso estructurado para clasificarlo y corregirlo antes de que se convierta en una brecha.

Los números son contundentes. El informe de costos de brechas de datos 2024 de IBM sitúa el costo promedio de una brecha en 4,88 millones de dólares a nivel global. Para una startup en etapa semilla, esa cifra es existencial. Mientras tanto, montar un VDP no cuesta nada más allá del tiempo de ingeniería. Compáralo con una prueba de penetración, que suele costar entre 15.000 y 50.000 dólares por evaluación.

La presión regulatoria también se acelera. La Directiva NIS2 de la UE, vigente desde octubre de 2024, exige a las organizaciones en sectores críticos implementar divulgación coordinada de vulnerabilidades. Las normas de ciberseguridad de la SEC de EE. UU. de 2023 exigen que las empresas públicas reporten incidentes materiales en un plazo de cuatro días hábiles. Los auditores de SOC 2 piden cada vez más evidencia de recepción externa de vulnerabilidades, y varios Trust Services Criteria (CC7.1, CC7.2) se alinean directamente con las capacidades de un VDP. Si planeas vender a clientes enterprise, tener un VDP publicado aparece en los cuestionarios de seguridad. Las preguntas sobre gestión de vulnerabilidades son ahora estándar en las evaluaciones de seguridad de proveedores, y un VDP les da a los equipos de compras una respuesta inmediata que acorta tu ciclo de venta.

VDP vs. Bug Bounty: ¿cuál va primero?

Un VDP es la base. Un bug bounty añade una capa de incentivo financiero encima. Arrancar con un bug bounty antes de poder manejar el volumen de reportes es un error común y costoso.

El informe Hacker-Powered Security 2024 de HackerOne encontró que el 77% de las organizaciones que ejecutan bug bounties empezaron primero con un VDP. La tesis es simple: construye el proceso antes de agregar el presupuesto. Una startup de cinco personas no puede igualar la velocidad de triaje de Google, pero sin duda puede gestionar un VDP profesional.

Las cuatro fases de implementación de un VDP

Lanzar un VDP no es un proyecto de fin de semana, pero tampoco requiere meses de planificación. El proceso se divide en cuatro fases que un solo ingeniero puede completar en una semana.

Fase 1: Definición del alcance

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

Dentro del alcance: aplicaciones web en producción, APIs públicas, apps móviles, subdominios específicos que controlas. Fuera del alcance: infraestructura corporativa interna, cuentas de empleados, herramientas SaaS de terceros (Stripe, Intercom) y seguridad física.

Un alcance demasiado amplio es peligroso para una empresa en etapa semilla. Tu equipo de ingeniería tiene capacidad limitada para clasificar hallazgos. Si un investigador reporta una vulnerabilidad en un entorno de staging que olvidaste que estaba público, necesitas poder responder. Un alcance demasiado estrecho envía una señal diferente. Limitar tu VDP a una sola página de marketing mientras tu superficie de ataque real incluye APIs y apps móviles les dice a los investigadores que no vas en serio.

El punto ideal: incluye todo lo que tus clientes tocan. Eso significa apps web en producción, APIs públicas y cualquier cliente móvil que distribuyas. Excluye lo que no puedes arreglar (integraciones de terceros, infraestructura gestionada por proveedores).

Fase 2: Mecanismos de reporte y security.txt

Los investigadores necesitan un canal seguro y confiable para enviar sus hallazgos. El enfoque mínimo viable es una dirección de correo dedicada [email protected] con cifrado PGP. Para startups que reciben más de un puñado de reportes al mes, un formulario web estructurado o una plataforma gestionada (HackerOne Response, Bugcrowd VDP, Intigriti) ahorra un tiempo significativo de triaje.

Independientemente del canal que elijas, el mecanismo de descubrimiento está estandarizado: security.txt. Definido en RFC 9116, es un archivo de texto plano legible por máquinas en /.well-known/security.txt que indica a los investigadores exactamente dónde y cómo reportar vulnerabilidades.

Un security.txt completo se ve así:

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

El campo Expires es obligatorio. Configúralo con un máximo de un año de anticipación y pon un recordatorio recurrente en el calendario para actualizarlo. Un security.txt expirado señala un programa sin mantenimiento, lo cual es peor que no tener ninguno. Según datos de securitytxt.org, solo alrededor del 1,25% del millón de sitios web principales publica un archivo security.txt a fecha de 2025, frente a aproximadamente el 0,5% en 2022. La baja adopción significa que el tuyo destacará ante los investigadores. Publica el tuyo antes de necesitarlo.

Fase 3: Política de puerto seguro (Safe Harbor)

Este es el componente jurídicamente más sensible de tu VDP. Sin un lenguaje claro de puerto seguro, los investigadores no te reportarán. Les preocupará ser procesados bajo la Computer Fraud and Abuse Act (CFAA) en EE. UU. o leyes equivalentes a nivel internacional.

La guía del Departamento de Justicia de 2022 sobre la CFAA establece explícitamente que “la investigación de seguridad de buena fe no debería ser procesada penalmente.” Tu cláusula de puerto seguro debe incluir cuatro compromisos: la promesa de no emprender acciones legales contra investigadores que sigan la política, el compromiso de no invocar la CFAA o la DMCA en investigaciones de buena fe, la declaración de que trabajarás con los investigadores si terceros inician acciones legales, y el reconocimiento de que la investigación realizada dentro de la política está autorizada.

Un puerto seguro mal redactado puede exponer a la empresa a responsabilidad legal o no proteger a los investigadores, haciendo que eviten reportar por completo. Empieza con las plantillas comunitarias de disclose.io, que han sido revisadas por equipos legales de EFF, Dropbox y Bugcrowd. Luego, haz que tu propio equipo jurídico las revise. La mayoría de abogados de startups pueden resolverlo en 24 horas.

No redactes el lenguaje de puerto seguro desde cero. Es un documento legal. Las plantillas de disclose.io existen precisamente para que las startups no tengan que pagar 10.000 dólares en honorarios legales para escribir uno.

Fase 4: SLAs internos y proceso de triaje

El tiempo de respuesta es la señal más fuerte de si tu VDP es real o pura fachada. El Success Index de HackerOne muestra consistentemente que los programas con tiempos de respuesta rápidos atraen significativamente más reportes y de mayor calidad. Los investigadores hablan entre ellos. Si tres personas reportan problemas y no reciben respuesta, tu programa está efectivamente muerto.

Define y publica estos SLAs, calibrados según lo que un equipo pequeño realmente puede cumplir:

Usa CVSS 4.0 (especificación de FIRST.org, publicada en noviembre de 2023) para la puntuación de severidad. No inventes tu propia escala. CVSS es imperfecto, pero es un lenguaje compartido entre tu equipo y la comunidad de investigadores.

Construye un flujo de triaje que cubra cinco etapas: recepción (los reportes llegan a un canal dedicado), triaje (un ingeniero evalúa la severidad con CVSS), seguimiento (crea un ticket interno, nunca en issues públicos de GitHub), remediación (asigna al equipo correspondiente) y respuesta (actualiza al investigador en cada transición). Cuando se despliegue la corrección, notifica al investigador y ofrécele crédito en un salón de la fama público.

Marcos de cumplimiento que requieren un VDP

Un VDP no es solo buena práctica. Varios marcos ahora lo exigen explícitamente o lo incentivan fuertemente.

SOC 2 Type II no exige un VDP por nombre, pero los Common Criteria de evaluación de riesgos (CC3.2) y comunicación (CC2.3) son significativamente más fáciles de cumplir con una recepción documentada de vulnerabilidades externas. Los auditores cada vez lo esperan más.

ISO 27001:2022 El Control A.8.8 exige a las organizaciones “establecer e implementar reglas para la divulgación de vulnerabilidades.” Un VDP satisface directamente este control.

PCI DSS 4.0 El Requisito 6.3.1 obliga a identificar y gestionar vulnerabilidades de seguridad provenientes de fuentes externas. Un VDP demuestra cumplimiento con ese requisito.

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

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

Para una startup en etapa semilla, el argumento de cumplimiento es prospectivo. Puede que hoy no necesites SOC 2, pero tu primer contrato enterprise lo pedirá. Tener un VDP ya en marcha cuando llegue el auditor te ahorra meses de trabajo apresurado.

De VDP a Bug Bounty: cuándo agregar recompensas financieras

Una vez que tu VDP lleve de tres a seis meses funcionando con un flujo de triaje confiable, puedes considerar añadir recompensas. Estás listo cuando tu tiempo promedio de primera respuesta es inferior a 24 horas, has corregido al menos el 80% de las vulnerabilidades reportadas dentro de tus SLAs publicados, y tu equipo de ingeniería tiene un proceso para priorizar correcciones de seguridad junto con el trabajo de funcionalidades.

Los montos de las recompensas deben reflejar el impacto real. Los datos de HackerOne de 2024 muestran pagos medianos: Crítica (ejecución remota de código, bypass de autenticación): de 3.000 a 15.000 dólares. Alta (XSS almacenado, IDOR con exposición de PII): de 1.000 a 5.000 dólares. Media (XSS reflejado, divulgación de información): de 250 a 1.000 dólares. Baja (redirección abierta, errores verbosos): de 50 a 250 dólares.

Para startups, empezar por el extremo inferior está bien. A los investigadores les importa más la capacidad de respuesta y el respeto que los pagos máximos. Un programa que paga 500 dólares y responde en 4 horas atraerá mejor talento que uno que paga 5.000 dólares e ignora reportes durante semanas.

Cómo Kit gestiona la divulgación de vulnerabilidades

Kit incluye un módulo CSIRT (Equipo de Respuesta a Incidentes de Seguridad Informática) integrado que trata la divulgación de vulnerabilidades como un flujo de trabajo de primera clase.

El módulo incluye un portal de seguridad personalizable en tu dominio donde los investigadores envían reportes estructurados: tipo de vulnerabilidad, activos afectados, pasos de reproducción y evaluación de impacto. Se acabaron los correos de texto libre o los reportes perdidos en una bandeja de entrada compartida. Cada reporte fluye a través de un flujo de triaje definido con SLAs configurables. Kit registra automáticamente el tiempo hasta la primera respuesta, el tiempo hasta el triaje y el tiempo hasta la resolución. Cuando se acerca una fecha límite, el miembro del equipo asignado recibe una notificación. Cuando se supera, se activan las reglas de escalada.

Kit genera y mantiene tu archivo security.txt automáticamente, incluyendo el campo obligatorio Expires con una verificación recurrente que te avisa antes de que caduque. El portal de seguridad es compatible con dominios personalizados, así que los investigadores interactúan con security.tuempresa.com en lugar de la URL de una plataforma de terceros.

El módulo también incluye un salón de la fama público, integración con Slack para notificaciones de reportes en tiempo real y comunicación con investigadores a través del propio portal. Los desembolsos para pagos de bug bounty se registran con un libro mayor completo, dándote registros listos para auditoría cuando llegue tu revisión de SOC 2 o ISO 27001.

Para startups que necesitan infraestructura tanto de contratación como de seguridad, gestionarlo todo desde una sola plataforma significa un proveedor menos, un cuestionario de seguridad menos y un inicio de sesión menos para tu equipo.

Lanza tu VDP esta semana

No necesitas meses de planificación. Esto es lo que un solo ingeniero puede lograr en cinco días.

Día 1 a 2: Redacta la política. Empieza con las plantillas de disclose.io. Define el alcance. Que el equipo jurídico revise el lenguaje de puerto seguro.

Día 3: Configura el canal de recepción. Configura un correo security@ con PGP, o monta un formulario web. Publica tu security.txt en /.well-known/security.txt.

Día 4: Construye el flujo de triaje. Define quién recibe los reportes, cómo se evalúa la severidad y cómo se rastrean las correcciones internamente.

Día 5: Prueba enviando un reporte a través de tu propio proceso. Verifica que los correos de confirmación se envíen, que el flujo de triaje enrute correctamente y que las plantillas de respuesta sean claras. Luego anúncialo: añade un enlace en el footer de tu sitio, publica en tu blog de ingeniería y notifica a las comunidades de seguridad relevantes.

Un VDP no es un proyecto puntual. Es un compromiso operativo continuo con tus usuarios. La configuración toma una semana. La credibilidad que construye se acumula durante años. Empieza ahora, mientras todavía es una ventaja competitiva y no una casilla regulatoria que estás corriendo a cumplir.