Bug Bounty y Vulnerability Disclosure: Guía Completa para Programas de Recompensas (2026)

Los programas de bug bounty y divulgación de vulnerabilidades (VDP) se han consolidado como un componente esencial de la seguridad en organizaciones de todos los tamaños. En 2026, miles de organizaciones — desde startups hasta gobiernos — invitan a investigadores externos a encontrar y reportar vulnerabilidades en sus sistemas a cambio de recompensas monetarias o reconocimiento.

Este artículo cubre todo lo que necesitas saber: desde la diferencia entre un VDP y un bug bounty, hasta cómo estructurar un programa, el marco legal safe harbor, y cómo participar como investigador.

1. VDP vs Bug Bounty: Diferencias Clave

Característica	VDP (Vulnerability Disclosure Program)	Bug Bounty
Recompensa económica	No (solo reconocimiento)	Sí (monetaria)
Costo	Bajo (proceso + plataforma)	Alto (recompensas continuas)
Volumen de reportes	Bajo-medio	Alto
Mejor punto de partida	Sí	Después de madurez en VDP
Motivación del investigador	Divulgación ética, CVEs	Incentivo económico
Cobertura	Amplia (todo tipo de bugs)	Enfocada en vulnerabilidades críticas

La mayoría de las organizaciones comienzan con un VDP, desarrollan madurez interna de triaje, y luego evolucionan a un bug bounty cuando están listas para manejar un volumen mayor de reportes.

2. Cómo Estructurar un Programa de Divulgación

Paso 1: Definir el Alcance (Scope)

El alcance es la decisión más importante y la que más fricción causa cuando se define mal.

In scope (ejemplos):

Sitios web y aplicaciones web de producción
APIs públicas
Aplicaciones móviles oficiales
Código open source del proyecto

Out of scope (ejemplos):

Bases de datos de producción
Sistemas de terceros
Dispositivos físicos de empleados
Ataques de denegación de servicio (DoS)
Ingeniería social contra empleados

# Ejemplo de política de alcance en security.txt
scope:
  in:
    - "https://*.ejemplo.com"
    - "https://api.ejemplo.com/*"
  out:
    - "https://admin.ejemplo.com"  # sistema interno
    - "ataques de phishing a empleados"

Paso 2: Definir Safe Harbor

El safe harbor es la protección legal que la organización otorga a los investigadores que actúan de buena fe. Sin safe harbor, los investigadores se exponen a acciones legales incluso cuando reportan vulnerabilidades de forma responsable.

La organización Disclose.io proporciona lenguaje boilerplate que ha sido revisado por abogados especializados en ciberseguridad:

Política de Safe Harbor:
Consideramos que la investigación y divulgación de vulnerabilidades realizadas 
de acuerdo con esta política constituyen:
- Uso autorizado de los sistemas objeto de la investigación
- Una exención de cualquier restricción en los Términos de Servicio que 
  entraría en conflicto con la investigación
- Una exención de responsabilidad civil, penal o administrativa, siempre que 
  la investigación se realice de buena fe y dentro del alcance definido

Paso 3: Publicar security.txt (RFC 9116)

El archivo security.txt es un estándar del IETF (RFC 9116) que permite a los investigadores encontrar la política de divulgación de una organización de forma estandarizada. Debe alojarse en https://ejemplo.com/.well-known/security.txt o en la raíz del sitio.

# https://ejemplo.com/.well-known/security.txt
Contact: mailto:security@ejemplo.com
Encryption: https://ejemplo.com/pgp-key.txt
Acknowledgments: https://ejemplo.com/hall-of-fame
Policy: https://ejemplo.com/vdp-policy
Preferred-Languages: es, en
Canonical: https://ejemplo.com/.well-known/security.txt
Expires: 2027-07-05T00:00:00.000Z

Paso 4: Establecer SLAs (Service Level Agreements)

Un VDP sin SLAs no es un programa — es un buzón de correo abandonado. Los investigadores necesitan saber qué esperar:

Etapa	SLA recomendado
Acuse de recibo	24-72 horas
Triaje y validación	1 semana
Corrección (Crítica/Alta)	30 días
Corrección (Media/Baja)	90 días
Divulgación pública coordinada	90-120 días o tras el parche

Paso 5: Elegir una Plataforma

Plataforma	Especialidad	Costo
HackerOne	Bug bounty y VDP	Comisión sobre recompensas
Bugcrowd	Bug bounty y VDP	Suscripción + comisión
Intigriti	Bug bounty (Europa)	Comisión sobre recompensas
YesWeHack	Bug bounty (Europa)	Comisión sobre recompensas
Propia (self-hosted)	VDP solo	Costo de infraestructura

3. Cómo Participar como Investigador

Para investigadores que quieren empezar en bug bounty:

Preparación

Conocimientos sólidos: OWASP Top 10, API Security Top 10, fundamentos de red y aplicaciones web
Herramientas básicas: Burp Suite Professional, navegador con herramientas de desarrollo, curl, nmap
Cuentas en plataformas: HackerOne, Bugcrowd, Intigriti, YesWeHack

Ética y Legalidad

Nunca atacar sin autorización explícita: opera solo dentro del alcance definido
No extraer ni modificar datos de usuarios reales: usa tus propias cuentas de prueba
No revelar públicamente sin coordinación: sigue la política de divulgación del programa
Documentar todo: cada paso, cada petición, cada respuesta

Cómo Reportar una Vulnerabilidad

Un buen reporte de vulnerabilidad debe incluir:

Título claro: SQL Injection en endpoint /api/users/search
Descripción: contexto de la vulnerabilidad y por qué es relevante
Pasos para reproducir: secuencia exacta de peticiones, con valores
Impacto: qué podría hacer un atacante con esta vulnerabilidad
Evidencia: capturas de pantalla, peticiones HTTP (sin datos sensibles)
CVSS score: puntuación estimada usando el calculador de FIRST
Sugerencia de mitigación: recomendación para corregir la vulnerabilidad

# Ejemplo de reporte: IDOR en endpoint de facturas
GET /api/v2/invoices/32459 HTTP/1.1
Host: app.ejemplo.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

# Respuesta: datos de la factura 32459 perteneciente a otro usuario
# Impacto: cualquier usuario autenticado puede acceder a facturas de 
# cualquier otro usuario cambiando el ID en la URL
# CVSS: 7.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)

4. El Ciclo de Vida de una Vulnerabilidad

El OWASP Vulnerability Disclosure Cheat Sheet define el ciclo de vida estándar:

1. Descubrimiento → 2. Reporte → 3. Acuse de recibo → 4. Triaje →
5. Validación → 6. Asignación CVE → 7. Desarrollo del parche →
8. Pruebas del parche → 9. Despliegue → 10. Divulgación pública coordinada

Coordinated Vulnerability Disclosure (CVD)

La divulgación coordinada busca un equilibrio entre la divulgación completa (publicar inmediatamente) y la no divulgación (ocultar el problema):

El investigador reporta en privado al fabricante
El fabricante desarrolla un parche en un plazo acordado (típicamente 90 días)
Ambos coordinan la publicación simultánea del advisory y el parche
El investigador recibe crédito (CVE, Hall of Fame, recompensa)

5. Tendencias en Bug Bounty 2026

Aumento de programas públicos

Según el State of Hacktivism 2026 de HackerOne, el número de programas públicos de bug bounty ha crecido un 40% respecto a 2024. Los sectores con más programas son: tecnología, banca/fintech, gobierno y salud.

Pausa del programa de curl

En mayo de 2026, Daniel Stenberg (mantenedor de curl) pausó el programa de bug bounty de curl, citando que el esfuerzo de triaje superaba la capacidad del equipo voluntario. Esto refleja una tendencia importante: los programas de bug bounty requieren infraestructura de triaje dedicada; no son apropiados para proyectos mantenidos por voluntarios sin recursos.

Expansión de CNAs (CVE Numbering Authorities)

Más organizaciones están emitiendo sus propios CVEs directamente, en lugar de depender de MITRE o de CNAs externos. Esto acelera el proceso de asignación y reduce los cuellos de botella en la divulgación.

Checklist para Organizaciones

Publicar security.txt en /.well-known/security.txt
Definir alcance claro (in scope y out of scope)
Incluir safe harbor language en la política
Establecer SLAs de respuesta (24h/72h/1 semana)
Designar equipo de triaje con capacidad de validación técnica
Empezar con VDP antes de bug bounty
Reconocer públicamente a los investigadores (Hall of Fame)
Establecer proceso de divulgación coordinada (CVD)
Probar el programa internamente antes de lanzarlo

Checklist para Investigadores

Leer y entender la política del programa antes de empezar
Operar solo dentro del alcance autorizado
Usar cuentas de prueba propias, nunca datos reales de usuarios
Documentar cada paso con evidencia reproducible
Reportar por el canal oficial (no por redes sociales)
No revelar públicamente hasta que el programa autorice
Usar PGP para comunicación cifrada si el programa lo requiere
No automatizar ataques sin verificar primero manualmente

Conclusión

Los programas de bug bounty y divulgación de vulnerabilidades son una de las formas más efectivas de mejorar la seguridad de un producto. Para las organizaciones, la clave está en empezar con un VDP bien estructurado — con safe harbor, alcance claro y SLAs definidos — antes de escalar a un bug bounty con recompensas monetarias. Para los investigadores, la ética y la documentación rigurosa son tan importantes como las habilidades técnicas. En un ecosistema donde cada vez más organizaciones abren sus puertas a la colaboración externa en seguridad, los programas bien gestionados benefician a todos.