« Módulo anterior☰ Índice del curso
Módulo 16 · Bug Bounty: Metodología Real

Construir tu pipeline de hunter

Convertir todo lo anterior en una rutina repetible y sostenible, en vez de depender de la motivación de cada sesión suelta de caza. Este es el módulo que separa a quien cobra de forma consistente de quien tiene un hallazgo bueno una vez y luego se estanca.

Metodología

📋 Índice de contenidos

  1. Objetivo
  2. Teoría
  3. Resumen operativo

01Objetivo

Convertir todo lo anterior en una rutina repetible y sostenible, en vez de depender de la motivación de cada sesión suelta de caza. Este es el módulo que separa a quien cobra de forma consistente de quien tiene un hallazgo bueno una vez y luego se estanca.

02Teoría

Por qué un pipeline importa más que la técnica individual

Cada módulo anterior enseña una habilidad puntual (recon, IDOR, JWT, reportes). Un pipeline es lo que decide, cada semana, en qué programas y categorías invertir esas habilidades, con qué herramientas, y cómo capitalizar el conocimiento de una campaña en la siguiente en vez de empezar de cero cada vez.

Los componentes de un pipeline personal

  1. Cartera de programas activa, con notas por programa. Para cada programa: fecha de última campaña, vectores ya agotados (módulo 12), categorías pendientes de probar, ritmo de respuesta de triage observado. Sin esto, cada vuelta a un programa repite recon ya hecho.
  2. Plantillas reutilizables, no empezar cada reporte desde cero: plantilla de reporte (módulo 14), checklist de JWT (módulo 9), checklist de IDOR (módulo 7), como documentos vivos que se consultan en cada sesión.
  3. Entorno de pruebas preconfigurado por tipo de programa (módulo 11): perfiles de Burp con Match & Replace y Session Handling ya montados para los patrones más comunes (apps móviles con cabecera de firma, SPAs con JWT en Authorization header), para no reconfigurar de cero en cada programa nuevo.
  4. Rutina de tiempo, no sesiones aleatorias: bloques fijos dedicados a recon (que puede hacerse en paralelo a otras tareas, es pasivo) separados de bloques dedicados a explotación activa (que requiere atención completa), separados de bloques dedicados a redacción de reportes (que se degrada mucho si se hace con prisa al final del día).

Dentro de cada bloque de explotación activa, dos reglas de disciplina evitan el desperdicio de tiempo más común:

  1. Revisión retrospectiva periódica. Cada mes o cada campaña: ¿qué categorías están rindiendo mejor para ti específicamente? ¿qué tipo de programa (ecommerce, fintech, red social, VDP gubernamental) te da mejor ratio de aceptación? Esto no es igual para todos los hunters — cada uno desarrolla ventaja comparativa en ciertas categorías o tipos de objetivo, y el pipeline debe ajustarse a esa ventaja real, no a la que "debería" tener según lo que mejor paga en general.

Automatización razonable vs. automatización que rompe la policy

Automatizar recon pasivo (módulo 3) y la organización de notas es seguro y rentable. Automatizar pruebas activas masivas (fuzzing amplio, escaneo agresivo) casi siempre viola la policy de programas serios (módulo 2) y es la forma más rápida de que un programa banee a un hunter. La automatización del pipeline se centra en reducir fricción operativa (organización, plantillas, configuración repetida), no en sustituir el juicio de priorización y la prueba manual dirigida que enseña el resto del curso.

Cierre del curso: de metodología a oficio

Los 15 módulos anteriores dan la metodología. Este módulo es el que la convierte en algo sostenible en el tiempo: sin un pipeline, cada campaña se siente como empezar de cero; con uno, cada campaña nueva parte del conocimiento acumulado de todas las anteriores — que es, en última instancia, la única ventaja real y duradera que tiene un hunter experimentado sobre uno que acaba de empezar.

03Resumen operativo

  1. Un pipeline personal es más valiosa a largo plazo que cualquier técnica individual del curso.
  2. Mantén cartera de programas con notas, plantillas reutilizables y entorno preconfigurado por tipo de programa.
  3. Separa recon (paralelo/pasivo), explotación (atención completa) y redacción (sin prisa) en bloques de tiempo distintos.
  4. Abre cada sesión de explotación con Define-Selecciona-Ejecuta, y pon un tope de 45 min por parámetro antes de pasar al siguiente.
  5. Automatiza fricción operativa, nunca la prueba activa misma — eso sigue siendo manual, dirigido y dentro de policy siempre.
« Módulo anterior☰ Índice del curso