Bug bounty: guía completa para empezar (2026)

El bug bounty es un modelo por el que empresas pagan a investigadores de seguridad independientes por encontrar y reportar vulnerabilidades en sus sistemas antes de que lo hagan los atacantes. La idea es simple: nadie conoce mejor los fallos de un producto que alguien que intenta romperlo con rigor y sin restricciones de departamento. Lo que no es tan simple es ganarse la vida con ello.

Esta guía te explica cómo funciona el ecosistema, qué plataformas existen, qué necesitas aprender antes de empezar y qué puedes ganar de forma realista. No te va a vender un curso ni te va a prometer que dejarás el trabajo en seis meses. Lo que sí encontrarás es información verificada y honesta para que tomes decisiones con los ojos abiertos.

Qué es el bug bounty y cómo funciona

Una empresa publica un programa de bug bounty: define un scope (qué sistemas son objetivo legítimo), unas reglas de comportamiento y una escala de recompensas según gravedad. Un investigador —llamado hunter o researcher— encuentra una vulnerabilidad dentro de ese scope, la documenta y la envía a través de la plataforma o directamente a la empresa. Si el informe es válido, reproducible y está dentro del scope, la empresa paga la recompensa y corrige el fallo.

El flujo habitual es:

1. El hunter elige un programa y lee el scope y las reglas con atención.
2. Realiza reconocimiento y pruebas dentro del scope autorizado.
3. Documenta la vulnerabilidad: pasos para reproducirla, impacto, captura de pantalla o vídeo.
4. Envía el informe. La empresa lo tría (valida, duplicado o fuera de scope).
5. Si es válido, asignan una severidad (CVSS o escala propia) y pagan la bounty.
6. Coordinación sobre el arreglo; en programas transparentes, el hunter puede hacer divulgación pública transcurrido un plazo.

La severidad determina el pago. La escala más usada es CVSS (Common Vulnerability Scoring System), que va de 0 a 10. Las plataformas la complementan con criterios propios de impacto de negocio. Un IDOR (Insecure Direct Object Reference) que expone datos de cualquier usuario puede ser un Critical con cuatro cifras; un XSS reflejado de bajo impacto puede quedar en tres cifras o menos.

Plataformas principales: diferencias y cuándo usar cada una

La plataforma importa porque define el acceso a programas, la visibilidad y, en algunos casos, la reputación que determina si te invitan a programas privados.

HackerOne

HackerOne es la plataforma más grande por volumen de programas y hunters registrados. La usan empresas como Google, Twitter (ahora X), Coinbase y múltiples agencias gubernamentales (NCSC UK, US DoD). Tiene programas públicos (cualquier hunter registrado puede participar) y privados (solo por invitación). El sistema de reputación —puntos de señal— es clave: empezarás en los programas públicos y, con buenos informes, recibirás invitaciones a privados, donde hay menos competencia y mejores recompensas. Los informes estadísticos anuales de HackerOne (Hacker-Powered Security Report) son la fuente de datos más citada del sector.

Bugcrowd

Bugcrowd compite directamente con HackerOne. Tiene un sistema de prioridad propio (P1-P4) y su propia escala de clasificación VRT (Vulnerability Rating Taxonomy). Cuenta con programas de empresas tecnológicas, fintech y del sector de salud. El Bugcrowd Inside the Platform Report publica datos anuales comparables a los de HackerOne.

Intigriti

Intigriti tiene origen europeo (Bélgica) y es la plataforma dominante en el mercado europeo. Sus clientes son principalmente empresas con sede en Europa, lo que puede ser relevante para hunters hispanohablantes. El proceso de validación es más manual que en las grandes plataformas anglosajones; algunos hunters reportan tiempos de respuesta más largos, pero también menos competencia en ciertos programas.

YesWeHack

YesWeHack es otra plataforma europea (francesa), con buena presencia en Francia, España y Alemania. Tiene la ventaja de que el soporte y algunos programas operan parcialmente en francés y español. Interesante para empezar si el inglés es una barrera inicial, aunque los mejores programas siguen operando en inglés.

Synack

Synack es diferente: no es una plataforma abierta. Para acceder hay que pasar un proceso de selección técnica riguroso (pruebas de habilidades, verificación de identidad). A cambio, los hunters del SRT (Synack Red Team) trabajan con empresas grandes que pagan mejor y tienen programas con menos hunters compitiendo. Es la opción para hunters con experiencia probada que quieren profesionalizar el proceso.

Programas directos (sin plataforma)

Muchas empresas gestionan su propio programa sin plataforma intermediaria. Apple, Mozilla y el programa de la UE (EU-FOSSA) son ejemplos. Son más difíciles de encontrar —hay que buscarlos en security.txt del dominio o en la política de divulgación de la empresa— pero la relación directa puede ser más fluida.

VDP, programa público y programa privado: qué cambia

Antes de elegir un programa conviene entender estos tres modelos:

VDP (Vulnerability Disclosure Program)

Un VDP no paga recompensas económicas. La empresa acepta recibir informes de vulnerabilidades de forma responsable y se compromete a no tomar acciones legales contra el reporter que respete el scope. Es el mínimo viable de seguridad colaborativa. Útil para principiantes: sin presión de pago, puedes practicar el proceso de reporte sin competir por dinero. GitHub, muchas universidades y administraciones públicas tienen VDP.

Programa público con recompensas

Cualquier hunter registrado puede participar. Hay más competencia (las vulnerabilidades obvias suelen estar ya reportadas) pero también más oportunidades para aprender. El riesgo del duplicado —que alguien haya reportado el mismo fallo antes— es alto en los primeros meses.

Programa privado

Acceso solo por invitación. Menos hunters, más superficie sin explorar, mejores recompensas medias. Se accede mejorando la reputación en la plataforma mediante informes válidos en programas públicos. Es el objetivo realista a medio plazo.

Qué necesitas saber antes de empezar

El error más común del principiante es registrarse en HackerOne sin base técnica y lanzarse a buscar vulnerabilidades en programas de empresas grandes. El resultado suele ser frustración, informes inválidos y tiempo perdido.

El bug bounty no enseña hacking desde cero. Es la aplicación de habilidades ya adquiridas en un entorno controlado y legal. Lo que necesitas antes:

• Fundamentos de redes y HTTP: entender cómo funciona una petición HTTP, cabeceras, cookies, sesiones, CORS, autenticación.
• Hacking web: el grueso del bug bounty es vulnerabilidades web. OWASP Top 10 es el punto de entrada, pero necesitas entender el «por qué» de cada vulnerabilidad, no solo el nombre. Nuestra guía de hacking web cubre este bloque en profundidad.
• Programación básica: leer código (JavaScript, PHP, Python) para encontrar fallos lógicos. No hace falta ser desarrollador, pero sí entender qué hace un fragmento de código.
• Linux y línea de comandos: la mayoría de herramientas del hunter son CLI.

Si estás empezando desde cero, el camino más eficiente es la hoja de ruta de entrada a la ciberseguridad, luego los recursos gratuitos disponibles hoy y, cuando tengas base, el bloque de hacking web.

Cómo empezar paso a paso

1. Crear cuenta en una plataforma

Empieza con HackerOne o Bugcrowd: tienen más programas públicos y los mejores recursos educativos integrados. El registro es gratuito y no requiere verificación de identidad para los programas públicos.

2. Leer la documentación de la plataforma

HackerOne tiene un apartado de aprendizaje (Hacker101) que vale la pena repasar. Bugcrowd tiene tutoriales propios. Antes de tocar ningún programa, entiende cómo funciona el sistema de triaje, qué es un duplicado y cómo se calcula la severidad.

3. Elegir el primer programa con criterio

Criterios para el primer programa:

• Scope amplio (muchos subdominios o funcionalidades).
• Tiempo de respuesta corto (la plataforma muestra el SLA medio del programa).
• Programa activo con informes resueltos recientes (señal de que tríen bien).
• VDP o programa con recompensas bajas: menos hunters compitiendo en el nivel bajo.

Evita al principio los programas de empresas muy grandes (Google, Meta, Apple): tienen miles de hunters experimentados. La superficie «fácil» ya está cubierta.

4. Leer el scope y las reglas con detalle

El scope define qué está dentro y qué no. Atacar un sistema fuera del scope —aunque encontraras una vulnerabilidad crítica— puede tener consecuencias legales y descalifica el informe. Lee también las exclusiones: muchos programas excluyen ataques DoS, ingeniería social y vulnerabilidades en dependencias de terceros.

5. Empezar a explorar y documentar desde el primer momento

Toma notas de todo: endpoints descubiertos, parámetros, comportamientos inesperados. Muchos hunters usan Obsidian, Notion o simplemente archivos de texto. La documentación sirve tanto para el informe final como para no repetir trabajo.

Metodología del cazador: de cero a informe

No existe una metodología única, pero la mayoría de hunters experimentados siguen una estructura parecida.

Reconocimiento (recon)

El recon es la fase de mapeo: qué sistemas existen dentro del scope, qué tecnologías usan, qué superficie tiene la aplicación. Para aplicaciones web incluye:

• Enumeración de subdominios: herramientas como subfinder, amass o dnsx.
• Rastreo de endpoints: gau (GetAllURLs), waybackurls, katana.
• Detección de tecnologías: whatweb, cabeceras HTTP, código fuente.
• Identificar formularios, parámetros, APIs y puntos de carga de archivos.

El recon es donde se encuentra la superficie que otros no han mirado. Un subdominio olvidado, una API interna expuesta o un panel de administración con autenticación débil son descubrimientos frecuentes aquí.

Mapeo y selección de objetivos dentro del scope

Con el mapa completo, prioriza. No tiene sentido probar todos los endpoints al azar. Las áreas más productivas suelen ser:

• Funcionalidades de autenticación y gestión de sesión.
• Carga y proceso de archivos.
• APIs REST o GraphQL con parámetros de ID (candidatos a IDOR).
• Funcionalidades que involucran datos de otros usuarios.
• Integraciones de pago o partes del sistema con más impacto de negocio.

Pruebas y verificación

Antes de escribir el informe, la vulnerabilidad tiene que ser reproducible de forma consistente. Un fallo que solo se produce una vez no es un informe válido. Documenta cada paso con capturas de pantalla o vídeo y asegúrate de que no dependes de una condición de carrera difícil de reproducir.

Vulnerabilidades más reportadas y mejor pagadas

Los informes anuales de HackerOne y Bugcrowd publican los tipos de vulnerabilidades más frecuentes. Según el Hacker-Powered Security Report 2023 de HackerOne, las categorías más reportadas ese año fueron XSS, gestión de información incorrecta y IDOR. Las mejor pagadas, por impacto real, son:

• SSRF (Server-Side Request Forgery): especialmente en entornos cloud donde puede dar acceso al servicio de metadatos de la instancia. Las bounties de SSRF crítico pueden superar los 10.000 dólares en programas grandes.
• IDOR (Insecure Direct Object Reference): acceso a datos de otros usuarios cambiando un ID. La severidad depende del dato expuesto; puede ir de cientos a miles de dólares.
• Inyección SQL: cuando permite extracción de datos o escalada de privilegios. Menos frecuente en aplicaciones modernas pero paga bien cuando aparece.
• Autenticación rota y lógica de negocio: fallos en el flujo de autenticación, restablecimiento de contraseña o control de acceso basado en roles. La lógica de negocio es donde los scanners automáticos no llegan.
• RCE (Remote Code Execution): el techo del bug bounty. En programas de empresas grandes puede superar los 50.000 o incluso 100.000 dólares. Son raros y difíciles de encontrar.

El XSS reflejado sin impacto real suele ser el tipo peor pagado y el más enviado por principiantes. Los programas lo listan frecuentemente como low o informativo si no hay un vector de ataque claro.

Cómo escribir un buen informe

El informe es tan importante como la vulnerabilidad. Un fallo crítico mal documentado puede ser descartado o infravalorado. Un informe de calidad tiene:

Título claro y preciso

Indica el tipo de vulnerabilidad, el componente afectado y el impacto resumido. Ejemplo: «IDOR en /api/v1/users/{id} permite acceder al perfil completo de cualquier usuario sin autenticación.»

Resumen (una sola línea)

La versión de 140 caracteres del fallo: qué es, dónde está y qué permite hacer a un atacante.

Pasos para reproducir

Numerados, concretos y sin dar nada por supuesto. El triador tiene que poder reproducirlo en diez minutos. Incluye:

1. URL exacta o endpoint.
2. Método HTTP y parámetros.
3. Si requiere sesión autenticada: qué tipo de cuenta (no incluir credenciales reales, usa una cuenta de test).
4. Resultado esperado y resultado real.

Impacto

Explica qué puede hacer un atacante real con esta vulnerabilidad. No es suficiente decir «puede acceder a datos sensibles»: concreta qué datos, de cuántos usuarios, con qué consecuencias. El triador usa esto para asignar la severidad.

Material de soporte

Capturas de pantalla, vídeos (especialmente para PoC complejos), peticiones HTTP brutas desde Burp Suite o similar. Un vídeo de Proof of Concept bien editado puede marcar la diferencia en la severidad asignada.

Severidad sugerida (opcional pero útil)

Muchos hunters incluyen su evaluación CVSS. No es vinculante, pero ayuda al triador y demuestra madurez técnica.

Aspectos legales: lo que necesitas entender antes de empezar

El bug bounty existe en un marco legal complejo que varía por país. Participar en un programa legítimo dentro del scope reduce enormemente el riesgo, pero no lo elimina del todo.

Safe harbor

El safe harbor es la cláusula por la que la empresa se compromete a no tomar acciones legales contra el hunter que actúe dentro de las reglas del programa. No todos los programas lo tienen explícito. HackerOne recomienda a sus clientes incluirlo, pero no es obligatorio. Antes de participar en un programa, verifica que tiene safe harbor claro.

Respetar el scope a rajatabla

El scope define exactamente qué sistemas puedes probar. Probar algo fuera del scope —aunque sea adyacente o accidental— puede ser ilegal incluso con un programa de bug bounty activo. La Computer Fraud and Abuse Act (CFAA) en EE. UU. o la Ley 34/2002 y el Código Penal en España criminalizan el acceso no autorizado a sistemas informáticos con independencia de la intención.

Divulgación responsable

La divulgación responsable implica dar tiempo a la empresa para corregir el fallo antes de hacerlo público. El estándar más aceptado es 90 días (el que usa Google Project Zero). Publicar una vulnerabilidad sin avisar a la empresa, o antes de que la corrijan, puede tener consecuencias legales y daña la reputación dentro de la comunidad.

No causar daño real

Las pruebas deben estar acotadas al mínimo necesario para demostrar la vulnerabilidad. No extraer bases de datos enteras para demostrar un SQLi, no modificar datos de usuarios reales, no interrumpir el servicio. El PoC mínimo es el estándar ético y legal.

Cuánto se gana de verdad: datos reales y la realidad sin adornos

Este es el apartado donde la mayoría de guías mienten por omisión. La verdad es que la distribución de ingresos en bug bounty es extremadamente desigual.

Datos de plataformas

El Hacker-Powered Security Report 2023 de HackerOne (fuente oficial) reporta que más de 300 hackers han ganado más de 100.000 dólares en total a través de la plataforma. La recompensa media por vulnerabilidad válida es difícil de extraer de los informes públicos porque varía enormemente por sector: infraestructura crítica y fintech pagan mucho más que startups. Según datos publicados por HackerOne en su blog, la media de pago por vulnerabilidad en sus programas ronda los 1.000 dólares, pero esta cifra está muy sesgada hacia arriba por los outliers de RCE y SSRF críticos.

Bugcrowd publica en su Inside the Platform datos similares: la mayoría de hunters recibe pagos irregulares y pocos superan los 10.000 dólares anuales. Los hunters que publican sus ingresos en plataformas como Twitter/X son los que ganan más, lo que introduce un sesgo de supervivencia enorme.

La realidad para la mayoría

El bug bounty como fuente principal de ingresos es viable para una fracción pequeña de hunters: aquellos con años de experiencia, especialización profunda y, frecuentemente, acceso a programas privados de alta remuneración. La mayoría de hunters gana entre 0 y unos pocos miles de dólares al año, con ingresos irregulares y sin garantías.

Los factores que separan a los hunters que viven de ello del resto son:

• Especialización en nichos poco competidos (APIs, lógica de negocio compleja, GraphQL).
• Reputación construida durante años en plataformas, que da acceso a programas privados.
• Capacidad de hacer recon a escala y automatizar tareas repetitivas.
• Networking dentro de la comunidad (colaboración con otros hunters).

Para la mayoría, el bug bounty es un complemento de ingresos de un empleo principal en ciberseguridad. El mapa de certificaciones te da una visión de los caminos de carrera en el sector que generan empleo estable.

Herramientas esenciales del hunter

No necesitas un arsenal completo desde el día uno. Estas son las herramientas que aparecen en la mayoría de metodologías reales:

Proxy de intercepción

• Burp Suite Community Edition: gratuita, suficiente para empezar. El proxy intercepta y permite modificar peticiones HTTP entre el navegador y el servidor. Es la herramienta central del bug bounty web. La versión Pro (499 USD/año) añade el scanner activo y es la que usa el 90% de hunters profesionales.
• OWASP ZAP: alternativa gratuita y open source.

Recon y enumeración

• subfinder y amass: enumeración de subdominios.
• httpx: comprobar qué subdominios están activos.
• gau / waybackurls: extraer URLs históricas de la Wayback Machine y otras fuentes.
• katana: rastreador web rápido del equipo de ProjectDiscovery.
• nuclei: escáner de plantillas para vulnerabilidades conocidas. Útil para filtrar superficie, no para encontrar vulnerabilidades lógicas.

Análisis específico

• ffuf o feroxbuster: fuzzing de directorios y parámetros.
• sqlmap: detección de inyección SQL (usar con cuidado dentro del scope).
• interactsh (de ProjectDiscovery): para detectar vulnerabilidades out-of-band (SSRF, XXE).

Casi todas son open source y gratuitas. El kit completo corre bien en una máquina Linux con 8 GB de RAM. Si trabajas desde Windows, WSL2 o una VM con Kali/Parrot son las opciones más cómodas.

Cómo practicar antes de ir a producción

Practicar en sistemas sin autorización es ilegal. Estas son las alternativas legales y efectivas:

PortSwigger Web Security Academy

Es la mejor plataforma gratuita de aprendizaje de hacking web. Cubre desde los fundamentos hasta técnicas avanzadas (deserialization, prototype pollution, HTTP request smuggling) con laboratorios interactivos que simulan vulnerabilidades reales. El equipo de PortSwigger la mantiene actualizada y es la referencia que citan la mayoría de hunters cuando explican cómo aprendieron. Completamente gratuita en portswigger.net/web-security.

HackTheBox y TryHackMe

Plataformas de práctica de hacking en laboratorio controlado. HackTheBox tiene una sección específica de aplicaciones web y su modelo de máquinas activas/retiradas permite practicar con entornos parecidos a los de bug bounty. TryHackMe es más accesible para principiantes con rutas guiadas.

Programas con VDP o recompensas bajas

Una vez con algo de base, los programas VDP reales son el mejor campo de práctica. No compites por dinero, pero el proceso —reconocimiento, pruebas, informe— es idéntico al de un programa de pago.

Entornos vulnerables locales

DVWA (Damn Vulnerable Web Application), WebGoat, Juice Shop (OWASP): aplicaciones diseñadas para ser rotas, que puedes instalar localmente con Docker. Son útiles para aprender herramientas sin internet y sin riesgo.

Errores comunes del principiante

La mayoría de los primeros informes son rechazados. Estos son los errores más frecuentes:

• Atacar fuera del scope: el error más grave. Lee el scope dos veces antes de tocar nada.
• Reportar duplicados: una vulnerabilidad ya conocida por el programa. Es frustrante y no paga. El recon exhaustivo reduce la probabilidad, pero los duplicados son inevitables al principio.
• Informes sin reproducción: «encontré un XSS pero no sé exactamente cómo» no es un informe válido. Documenta cada paso antes de reportar.
• Exagerar la severidad: el primer XSS que se encuentra siempre parece crítico. El triador bajará la severidad si el impacto real no lo justifica. Exagerar sistemáticamente daña la reputación.
• Usar herramientas de escáner sin entender qué hacen: nuclei y ZAP pueden generar informes de falsos positivos que, si se envían sin verificar, quedan como inválidos.
• No leer las reglas del programa: cada programa tiene exclusiones específicas. Muchos excluyen los rate limiting issues, los clickjacking sin impacto real o las vulnerabilidades en subdominios de terceros. Reportar algo excluido es tiempo perdido.
• Rendirse demasiado pronto: los primeros meses son los más frustrantes. La curva de aprendizaje es real. La mayoría de hunters tarda entre seis meses y un año en conseguir el primer pago significativo.

Recursos y comunidad

El bug bounty es un ecosistema con una comunidad activa. Aprender de hunters con experiencia acorta mucho la curva.

Blogs y write-ups

Los write-ups son los informes públicos que los hunters publican tras la divulgación. Son la mejor fuente de aprendizaje real: explican qué encontraron, cómo lo encontraron y cómo lo reportaron. Fuentes:

• HackerOne Hacktivity: feed público de informes.
• Bug Bounty Writeups en Medium: colección comunitaria.
• Blogs individuales de hunters conocidos: NahamSec, Jason Haddix, LiveOverflow, stök.

Vídeo

YouTube tiene contenido de calidad variable sobre bug bounty. Los canales más citados por la comunidad son LiveOverflow (técnico, honesto sobre la dificultad), NahamSec (práctico, mucho recon) y John Hammond (variado, buenas bases).

Comunidades

• Discord de las propias plataformas (HackerOne, Bugcrowd).
• Reddit: r/bugbounty, activo y con buenas preguntas de principiantes.
• Twitter/X: la comunidad de bug bounty es activa aquí; seguir a hunters conocidos da visibilidad a técnicas y programas.

Certificaciones relacionadas

El bug bounty no requiere certificación, pero ciertas rutas formativas dan base técnica sólida. Los recursos para preparar el OSCP cubren penetration testing estructurado con overlap importante con bug bounty. Para el mapa completo de opciones de formación, el mapa de certificaciones de seguridad te da una vista general del ecosistema. Si todavía estás decidiendo tu especialización, la sección de guías tiene artículos sobre distintos caminos en ciberseguridad.

Hoja de ruta realista para el primer año

En lugar de un calendario exacto (que depende de cuánto tiempo le dediques), aquí tienes los hitos por fase:

Fase 1: base técnica (2-4 meses según dedicación)

• Completar los módulos de SQL injection, XSS, CSRF, SSRF e IDOR de PortSwigger Web Security Academy.
• Aprender a usar Burp Suite para interceptar y modificar peticiones.
• Practicar en entornos como HackTheBox (apartado web) o DVWA local.
• Leer 20-30 write-ups de bugs reales para entender cómo piensan los hunters.

Fase 2: primeros informes (meses 3-6)

• Registrarse en HackerOne o Bugcrowd.
• Elegir un programa VDP o de baja remuneración con scope amplio.
• Hacer recon completo y documentar la superficie.
• Enviar los primeros informes aunque sean informativos. El proceso de triaje es un aprendizaje en sí mismo.

Fase 3: primeros pagos y mejora continua (meses 6-12)

• Especialización en una o dos categorías de vulnerabilidad donde tengas más resultados.
• Ampliar el toolkit de recon.
• Buscar invitaciones a programas privados.
• Publicar write-ups de los bugs divulgados: da visibilidad y reputación.

FAQ

¿Es legal el bug bounty en España?

Sí, siempre que actúes dentro del scope y las reglas de un programa oficial. El Código Penal español (art. 197 bis) penaliza el acceso no autorizado a sistemas. La clave es «autorizado»: el programa de bug bounty te da esa autorización para los sistemas del scope. Fuera del scope, no hay autorización y aplica el tipo penal.

¿Necesito ser hacker para hacer bug bounty?

El bug bounty es hacking ético aplicado. Necesitas habilidades técnicas reales: no es suficiente con usar herramientas automatizadas sin entender qué hacen. La profundidad técnica necesaria varía por el tipo de vulnerabilidad: las de lógica de negocio requieren entender la aplicación en profundidad; las de inyección requieren dominar las técnicas correspondientes.

¿Puedo hacer bug bounty sin experiencia previa?

Sin experiencia, el primer paso es conseguirla: en laboratorios, plataformas de práctica y leyendo write-ups. El bug bounty no es el lugar para aprender desde cero sobre los sistemas de otras empresas. Esta guía de entrada a la ciberseguridad y los mejores recursos gratuitos son el punto de partida adecuado.

¿Cuánto tiempo lleva conseguir el primer pago?

Con dedicación consistente (varios días a la semana), entre seis meses y un año para hunters con base técnica previa. Sin base previa, más tiempo. Muchos hunters no consiguen ningún pago durante los primeros meses, lo cual es normal y esperado.

¿Qué diferencia a un hunter que gana bien del que no?

Especialización, profundidad técnica, capacidad de encontrar vulnerabilidades de lógica de negocio que los scanners no detectan, reputación en plataformas que da acceso a programas privados y, en muchos casos, dedicación a tiempo completo. No es algo que se consiga en poco tiempo.

¿El bug bounty es compatible con un empleo en ciberseguridad?

Sí, y es la combinación más frecuente. Muchos profesionales de seguridad —pentesters, analistas SOC, ingenieros de aplicaciones— hacen bug bounty en su tiempo libre. Las habilidades se complementan y el contexto laboral da perspectiva sobre los tipos de vulnerabilidad que importan en entornos reales. Consulta el mapa de certificaciones para orientarte sobre las rutas de carrera que generan empleo en el sector.

¿Puedo hacer bug bounty en programas de fuera de España/Europa?

Sí. La mayoría de programas son globales. Las plataformas como HackerOne operan bajo ley estadounidense, pero el safe harbor aplica independientemente de dónde esté el hunter. Eso no exime de la ley local: si la ley española es más restrictiva en algún aspecto, aplica igualmente. Para dudas específicas, un asesoramiento legal es lo correcto.

¿Vale la pena el OSCP para bug bounty?

El OSCP enseña penetration testing estructurado en entornos de red, con algo de web. Es valioso como base técnica y abre puertas en el mercado laboral, pero no está diseñado específicamente para bug bounty web. PortSwigger Academy cubre mejor el hacking web. El OSCP y el bug bounty son caminos complementarios, no sustitutos. Recursos para preparar el OSCP.