Cómo elegir tu primer programa de bug bounty

El programa que elijas decide si tu primer mes es productivo o se pierde en objetivos que no puedes probar. Este post trata de leer bien un scope, con un modelo de IA haciendo la primera pasada y tú tomando la decisión. Sigue a el loop y alimenta el armado del toolkit.

#Qué es un programa

Un programa de bug bounty es una oferta pública. Una organización nombra los activos que quiere que se prueben, fija las reglas para probarlos y pone recompensas por reportes válidos. La política es el contrato. Todo lo que haces queda dentro de lo que ella lista, y un reporte que se sale queda cerrado sin importar lo bueno que sea el bug. Algunos sitios también publican un archivo security.txt en /.well-known/security.txt con un contacto y un enlace a la política, que te dice a dónde van los reportes.

#Dentro del scope y fuera del scope

Cada política divide el mundo en activos que puedes probar y activos que no. Dentro del scope suele ser un conjunto de dominios, dominios wildcard, apps móviles o APIs. Fuera del scope es el resto, y a menudo incluye servicios de terceros que la organización usa pero no posee. Para un principiante la lista de fuera del scope importa más que la de dentro, porque ahí es donde pasan los accidentes. Un wildcard como *.example.com todavía puede excluir hosts específicos, así que lee las dos listas juntas.

#Las reglas que cierran reportes

Más allá de las listas de activos, una política fija reglas de enfrentamiento: límites de rate, si se permite el escaneo automatizado, qué clases de bug no se pagan y qué puedes hacer con cualquier dato al que llegues. Clases comunes fuera del scope para principiantes son el self-XSS, los security headers ausentes sin exploit y los reportes de scanners automatizados sin prueba manual. Reglas de enfrentamiento en bug bounty las explica a fondo.

#Lee un scope con el modelo, y luego chequéalo

Pega la política en un chat y pide tres listas: activos dentro del scope, activos fuera del scope y reglas que harían que un reporte se cierre. El modelo es bueno en este trabajo de lectura. También es capaz de soltar un host o inventar una regla, así que lees la política tú mismo después y corriges sus listas. Aquí el modelo sirve para ir rápido en una tarea aburrida, no para dar un veredicto que confías a ciegas.

Señal	Amigable para empezar	Arranque más difícil
Tamaño del scope	Pocos dominios claros	Gran patrimonio con wildcards
Madurez	Programa nuevo, menos hunters	Programa maduro, muy trabajado
Reglas	Escaneo permitido, clases claras	Rate limits estrictos, muchas exclusiones
Objetivos	Una web app que también corres local	Hardware o apps solo nativas

#Elige un activo que de verdad puedas probar

Un programa puede listar diez activos cuando solo dos encajan con tus habilidades. Como principiante, elige una aplicación web que también puedas estudiar en tu propia máquina, para aprender su comportamiento sin mandar tráfico al objetivo vivo por cada pregunta. Si el programa ofrece un build self-hosted o de demo, córrelo local y guarda el host vivo para confirmar un bug. Esto mantiene bajo tu número de requests sobre el objetivo real, lo que respeta las reglas de rate y deja un registro más limpio.

#Graba el scope antes de tocarlo

Anota el scope en algún lugar donde tus herramientas puedan chequearlo, no solo en tu memoria. La CLI de NotHoly puede guardar el scope de una corrida con notholy engage, y lee el objetivo de cada comando antes de que el comando corra, así que un host fuera del scope pide una segunda confirmación. El post del toolkit arma esto. Grabar el scope vuelve una regla que tienes que recordar en un chequeo que el terminal hace por ti.

#Elegir la plataforma

Los programas viven en plataformas de bounty y en páginas de empresa que se encuentran por security.txt o una página /security. Los programas públicos aceptan a cualquiera. Los privados llegan por invitación después de que construyes un historial. Empieza en público, lee algunas políticas con el modelo para sentir en qué se diferencian y quédate con un programa el tiempo suficiente para aprender bien su aplicación.

#Lo siguiente en esta serie

Una vez que tienes un programa y un activo, arma el toolkit y el terminal. Mantén cerca la OWASP Web Security Testing Guide y los términos de disclose.io como referencias de cómo se ve una prueba de buena fe.