Qué es bug bounty: programas, plataformas y rewards 2026

Un programa de bug bounty es una iniciativa continua mediante la cual una organización ofrece recompensa económica a investigadores externos por descubrir y reportar vulnerabilidades de seguridad de forma responsable. A diferencia de una auditoría puntual, el programa permanece abierto en el tiempo y convierte la superficie expuesta de la empresa en un objeto de prueba permanente por parte de una comunidad amplia, especializada y diversa. El primer programa moderno data de 1995 (Netscape), pero la categoría se consolida industrialmente con la aparición de plataformas como HackerOne y Bugcrowd a partir de 2012, y se generaliza entre administraciones, banca, retail y tecnología a lo largo de la siguiente década.

Lo esencial

• El bug bounty paga a investigadores externos por reportar vulnerabilidades de forma responsable y continuada.
• Las plataformas más usadas en 2026 son HackerOne, Bugcrowd, Yeswehack, Intigriti, Yogosha y Open Bug Bounty.
• Existen tres modelos: público (abierto), privado (invitación) y VDP (sin recompensa, solo canal formal).
• Los rangos de payout dependen de severidad y reputación del programa, no del coste interno de remediar.
• Lanzar un programa exige madurez previa de seguridad, IR runbook, política de safe harbor y un proceso de triage solvente.

Bug bounty frente a pentesting, red team y VDP

Estas cuatro figuras se confunden con frecuencia, pero responden a propósitos distintos y conviven en una estrategia de seguridad madura.

El bug bounty no sustituye al pentesting: complementa una base ya auditada. Una organización sin pentest previo que abre un programa público recibe un aluvión de hallazgos triviales que satura al equipo y deteriora la relación con la comunidad. El orden razonable es auditoría inicial, remediación, programa privado controlado y, solo cuando el flujo está estabilizado, apertura pública.

Plataformas principales activas en 2026

HackerOne es la plataforma de referencia global por volumen de programas y comunidad. Aloja desde programas pequeños hasta los más grandes del sector (defensa, banca, hiperescalares). Su servicio de triage gestionado descarga al cliente de la primera fase de validación. Tiene fortaleza en mercado norteamericano y precios premium.

Bugcrowd compite directamente con HackerOne en cuota global. Es muy frecuente en programas de empresa Fortune y administración estadounidense. Su rúbrica de severidad (VRT) es una referencia consultada incluso fuera de la plataforma.

Yeswehack es la plataforma de origen europeo con mayor presencia en la región. Tiene fortaleza específica en Francia, Benelux y mercado regulado europeo. Es la opción preferida cuando la empresa quiere mantener los datos del programa bajo jurisdicción europea por motivos de NIS2, ENS o sensibilidad sectorial.

Intigriti es la segunda plataforma europea relevante, con sede en Bélgica y crecimiento sostenido. Ha ganado tracción entre empresas mid-market europeas, fintech y administraciones que valoran proximidad y soporte en idiomas locales.

Yogosha opera principalmente en mercado francés y francófono, con foco en programas privados curados. Su modelo prioriza calidad de comunidad por encima de volumen, lo que encaja en sectores muy regulados.

Open Bug Bounty es un caso aparte. Es una plataforma sin ánimo de lucro centrada exclusivamente en vulnerabilidades web no intrusivas (XSS, open redirects) reportadas a propietarios identificados. No gestiona pagos: actúa como mediador para coordinar la divulgación. Es útil para investigadores que descubren bugs en sitios sin programa formal, pero su cobertura es limitada.

Modelos de programa: público, privado y VDP

Público (open): cualquier investigador puede registrarse, leer las reglas y enviar reportes. Maximiza alcance pero también ruido. Requiere un equipo de triage dimensionado y reglas muy claras. Es el modelo asociado a las grandes marcas tecnológicas y a buena parte de la administración. La sensación de exposición es alta, lo que se compensa con reputación y visibilidad hacia clientes.

Privado (invite-only): la plataforma selecciona o el cliente curra una lista de investigadores con perfil contrastado. El volumen de reportes es mucho menor, la calidad promedio mayor y la confidencialidad sobre la marca queda protegida. Es la entrada habitual al bug bounty para empresas que abren programa por primera vez. Muchas plataformas permiten escalar de privado a público una vez la operativa está rodada.

Vulnerability Disclosure Program (VDP): no contempla recompensa económica, solo un canal formal documentado para que cualquier investigador reporte vulnerabilidades. Es el mínimo que muchas regulaciones esperan de una organización seria. El documento security.txt (RFC 9116) en la raíz del dominio anuncia el canal y reduce la fricción para quienes quieren reportar. NIS2 y la futura CRA empujan a que cualquier entidad esencial o importante tenga al menos un VDP funcional.

La diferencia operativa entre VDP y bug bounty no es solo el reward. Un VDP comunica disposición a recibir reportes; un bug bounty asume el coste de incentivar la búsqueda activa. La inversión y los requisitos internos cambian significativamente.

Scope: qué se incluye y qué se excluye

Definir el scope con precisión es lo que separa un programa que funciona de uno que se ahoga en ruido. Hay decisiones técnicas y de negocio que deben estar resueltas antes de la publicación.

Activos incluidos: dominios de producción, APIs públicas, aplicaciones móviles publicadas en stores oficiales, infraestructura expuesta a internet. Se listan explícitamente con notación clara (wildcards solo cuando se asume su impacto).

Activos excluidos: entornos staging y desarrollo no productivos, infraestructura de terceros (incluso si la usa la empresa), servicios SaaS de proveedores, dominios corporativos con información solo informacional, adquisiciones recientes hasta integración.

Pruebas no permitidas: ataques de denegación de servicio, ingeniería social a empleados o clientes, ataques físicos, fuzzing masivo que afecte disponibilidad, accesos a datos reales de otros usuarios.

Time-boxing: algunos programas limitan ventanas (por ejemplo, no testear durante eventos comerciales críticos). Otros aplican rate limits específicos para no saturar logs y alertas.

Móvil: cuando se incluye, conviene definir versiones aceptadas, política sobre reverse engineering, dispositivos rooteados o con jailbreak, y manejo de datos extraídos durante la prueba.

Third-party y subprocesadores: nunca dentro de scope sin autorización explícita del tercero. Reportes que llegan sobre activos de terceros se rechazan y se redirigen.

Estructura de payout y rangos de mercado en 2026

Los rangos varían entre plataformas y programas, dependen de la reputación del activo, la madurez del equipo y la competitividad sectorial. Como orientación cualitativa para 2026:

Critical (RCE pre-auth, takeover de cuentas masivo, cross-tenant data exposure): rangos típicos desde 5.000 USD en programas mid-market hasta 50.000 USD o más en hiperescalares. Casos excepcionales en grandes tecnológicas o defensa han superado seis cifras.

High (auth bypass, SSRF a metadata cloud, IDOR con datos sensibles): entre 2.000 y 10.000 USD en programas competitivos.

Medium (XSS con impacto, CSRF en endpoints sensibles, divulgación de datos limitada): entre 500 y 2.500 USD.

Low (XSS sin impacto material, open redirects, divulgación de información menor): entre 100 y 500 USD, cuando se aceptan.

Informational: sin recompensa, pero pueden contar para reputación dentro del programa.

Un error frecuente es fijar el payout en función del coste interno de remediar. La referencia correcta es el coste de oportunidad del investigador frente a otros programas. Un Critical pagado a 1.000 USD desincentiva el envío serio: el investigador prefiere reportar el mismo bug en otro programa que pague diez veces más. La consecuencia no es que no se descubra, sino que se descubra fuera del programa.

Proceso de triage paso a paso

El recorrido típico de un reporte sigue una secuencia clara y debe estar documentada desde la página del programa.

1. Envío del reporte: el investigador completa la plantilla con título, descripción, pasos de reproducción, impacto, prueba de concepto y evidencias. Las plataformas serias rechazan reportes sin reproducibilidad.

2. Triage en plataforma: el equipo de la plataforma (o el cliente, si gestiona triage propio) valida que el bug existe, encaja en el scope y no es duplicado de un reporte previo.

3. Validación interna del vendor: el equipo de seguridad del cliente confirma el bug, asigna severidad inicial y abre ticket en el sistema de vulnerability management.

4. Discusión de severidad: si el investigador discrepa con la severidad asignada, abre dispute. La rúbrica del programa actúa como referencia. Plataformas como Bugcrowd publican su VRT para reducir desacuerdos.

5. Payout: una vez confirmada severidad, se procesa el pago según los rangos publicados. El plazo razonable es entre 7 y 30 días desde validación.

6. Remediación: el equipo de seguridad coordina el fix con desarrollo o con el proveedor externo. El investigador puede solicitar retest cuando el parche está desplegado.

7. Disclosure: cuando el bug está mitigado, se acuerda con el investigador si publicar resumen, mantener confidencialidad indefinida o publicar pasado un plazo. Algunos programas tienen política de transparencia que publica todos los reportes resueltos.

La métrica que más vigila la comunidad es el tiempo desde envío hasta primera respuesta humana y desde validación hasta payout. Un programa que tarda semanas en cada paso pierde investigadores rápidamente.

Cómo montar un programa propio

Antes de abrir un programa hay que tener resueltas varias piezas internas. Saltarse este paso genera caos operativo y deteriora la relación con la comunidad desde la primera semana.

Madurez de seguridad mínima: la organización ya ha pasado al menos un pentest reciente, ha remediado los hallazgos críticos y mantiene un programa básico de vulnerability management. Abrir bug bounty sobre superficie sin auditar previa garantiza saturación.

IR runbook activo: el equipo sabe escalar un Critical fuera de horario, tiene comunicación con desarrollo y puede desplegar fix de emergencia. Si no, recibir un Critical el viernes a las 20:00 será un problema mayor que la propia vulnerabilidad.

Marco legal y safe harbor: cláusula explícita que protege al investigador de acciones legales cuando actúa dentro de las reglas del programa. Sin safe harbor, los buenos investigadores no participan. La fórmula concreta varía por jurisdicción y debe revisarla un abogado especializado.

Elección de plataforma: el criterio principal es jurisdicción de los datos, comunidad disponible en el idioma del producto, modelo de triage que la empresa quiere asumir y presupuesto anual realista (fee de plataforma + payouts + tiempo interno).

Política de comunicación: respuesta inicial en plazo definido (24 a 72 horas), comunicación bilingüe si el producto opera en mercados distintos, transparencia sobre estado del bug y disposición a explicar decisiones de severidad.

Presupuesto: un programa privado modesto puede operar entre 30.000 y 80.000 USD anuales contando plataforma y payouts. Programas públicos de empresas medianas se mueven entre 150.000 y 500.000 USD anuales. Los gigantes tecnológicos pagan millones cada año.

Errores comunes que matan programas

Scope demasiado restrictivo: limitar el programa a dos subdominios secundarios genera la sensación de que la empresa no quiere encontrar bugs reales. Los buenos investigadores rotan a programas más generosos.

Payouts no competitivos: pagar por debajo de la media de mercado expulsa al perfil senior. El programa se llena de reportes informativos y duplicados de baja calidad.

Triage lento: tardar tres semanas en responder al primer reporte mata la motivación del investigador. La comunidad publica métricas y los programas con mala reputación lo notan en el flujo.

Disputas de severidad recurrentes: si los triadores rebajan sistemáticamente la severidad para reducir payout, se rompe la confianza. La rúbrica debe ser explícita, pública y aplicada con consistencia.

Sin hall of fame ni reconocimiento: el reward económico importa, pero la visibilidad también. Programas sin reconocimiento público pierden frente a programas que sí destacan a sus mejores contribuidores.

Cambios unilaterales de reglas: modificar el scope, los rangos o la política sin aviso retroactivo deteriora la relación. Los cambios deben anunciarse y respetar los reportes ya en curso.

Olvidar el VDP base: lanzar bounty sin un VDP claramente accesible deja fuera a quien descubre un bug sin querer participar en el programa formal. El security.txt es el mínimo razonable.

Encaje regulatorio: NIS2, ENS y EU CRA

NIS2 no obliga formalmente a tener bug bounty, pero la transposición española y la mayoría de europeas exigen políticas de divulgación coordinada de vulnerabilidades para entidades esenciales e importantes. Un VDP cubre el requisito; un bug bounty va más allá. El ENISA publica guías que tratan el bug bounty como herramienta avanzada de gestión de vulnerabilidades.

ENS (Esquema Nacional de Seguridad) en su nivel alto requiere procesos de gestión de vulnerabilidades documentados. Tener un canal formal de divulgación y, opcionalmente, un programa de recompensa, refuerza el cumplimiento y aporta evidencia ante auditoría.

EU Cyber Resilience Act (CRA) introduce obligaciones específicas para fabricantes de productos con componentes digitales. Los artículos sobre tratamiento de vulnerabilidades exigen política de divulgación coordinada, canal de reporte y procesos para notificar vulnerabilidades explotadas. El reglamento entra en aplicación progresivamente desde finales de 2026, con plazos completos hacia 2027 para la mayoría de obligaciones.

Otras referencias: la norma ISO/IEC 29147 sobre vulnerability disclosure y la ISO/IEC 30111 sobre vulnerability handling son las referencias internacionales para diseñar el proceso interno.

Preguntas frecuentes

¿Una pyme tiene sentido lanzar bug bounty? En la mayoría de casos, no como primera medida. El orden razonable es pentest inicial, remediación, VDP con security.txt y, si la superficie es relevante y hay madurez interna, programa privado curado. Saltar pasos genera más coste que valor.

¿Mi pentest anual basta sin necesidad de bug bounty? Para muchos perfiles sí. Pentest cubre auditoría puntual con metodología y entregable formal. Bug bounty cubre presión continua entre auditorías. Si la superficie cambia poco y el ciclo de releases es trimestral, el pentest puede ser suficiente. Si hay despliegues semanales y superficie creciente, el bug bounty aporta cobertura entre auditorías.

¿Vivir del bug bounty como freelance es realista? Para una minoría sí, para la mayoría no como ingreso único. Los hunters consistentes a tiempo completo en programas globales generan ingresos comparables a un perfil senior de seguridad. La curva de aprendizaje es larga, la competencia es alta y los ingresos son irregulares. Lo habitual es combinarlo con consultoría, formación o empleo.

¿Yeswehack frente a HackerOne para empresa europea? Yeswehack ofrece jurisdicción europea, soporte local y encaje cómodo con NIS2 y ENS. HackerOne tiene mayor comunidad global y más oferta de servicios gestionados. La elección depende de prioridad entre alcance global y proximidad regulatoria. Muchas empresas europeas optan por Yeswehack o Intigriti para el programa principal y mantienen presencia en HackerOne para casos puntuales.

¿GDPR aplica a los datos manejados por researchers? Sí. Cuando un investigador accede inadvertidamente a datos personales durante la prueba, debe pararse, no exfiltrar, reportar y borrar. El programa debe documentar este flujo. El responsable del tratamiento sigue siendo la empresa, no la plataforma ni el investigador.

¿Safe harbor es obligatorio? No por ley, pero sin safe harbor el programa atrae menos talento y los investigadores serios lo evitan. Es una pieza estándar en cualquier programa con ambición. La redacción concreta debe revisarse por jurisdicción.

Recursos relacionados

• AI bug bounty: programas y recompensas IA para el caso específico de modelos de IA.
• Qué es pentesting: guía para empresas si necesitas la base de auditoría previa al bug bounty.
• Qué es un CVE para entender cómo se cataloga e identifica una vulnerabilidad reportada.
• Qué es hacking ético para situar el bug bounty en el ecosistema de seguridad ofensiva legal.
• Qué es red team: guía para empresas si lo que necesitas es un ejercicio dirigido en lugar de un programa continuo.
• Cracker frente a hacker: diferencias para aclarar terminología cuando se comunica el programa internamente.

Programa bug bounty con Secra

Lanzar un bug bounty exige base sólida antes del primer reporte. En Secra ayudamos a preparar la organización para el programa: auditoría previa, definición de scope, redacción de reglas y política de safe harbor, dimensionamiento del triage y elección de plataforma según jurisdicción y madurez. También operamos triage gestionado para programas privados cuando el equipo interno no puede asumir la carga inicial. Si estás valorando abrir programa o necesitas profesionalizar uno ya activo, contacta con Secra y diseñamos el recorrido completo.