Metodología de bug bounty

Diferencias reales de enfoque frente a un pentest tradicional con Argus, y cómo aprovechar mejor el framework en ese contexto.

Diferencias clave vs. pentest de cliente

Scope más estricto y cambiante — un programa de bug bounty define scope por dominio/subdominio y a veces excluye técnicas específicas (DoS, ingeniería social, fuerza bruta agresiva). Revisar el scope del programa ANTES de tocar /scope set — Argus bloquea fail-closed fuera de scope, pero el scope que le des tiene que reflejar exactamente lo que el programa permite, no más.
Compites contra otros researchers — la velocidad de recon inicial importa más que en un engagement de cliente exclusivo. crtsh_subdomain_enum + cloud_storage_recon como primer paso, en paralelo, antes de que alguien más encuentre el mismo activo mal configurado.
El informe ES el producto — un cliente de pentest ve el trabajo completo aunque el reporte sea flojo; un triager de bug bounty solo ve el reporte. Claridad de impacto de negocio y pasos de reproducción exactos importan más que en un informe interno.
Duplicados no pagan — antes de reportar, vale la pena search_obsidian_vault con el nombre del programa/organización: si ya se reportó ese mismo patrón antes (en otro programa, con otro cliente), probablemente ya está mapeado en algún lado público.

Recon pasivo primero, siempre — crtsh_subdomain_enum, cloud_storage_recon, Shodan. Cero riesgo de romper reglas del programa, y define dónde vale la pena mirar activo.
Priorizar por superficie nueva, no por la más obvia — un subdominio de staging recién descubierto por crt.sh suele tener menos ojos encima que el dominio principal.
crawl_spa en cualquier SPA — la mayoría de bug bounty hunters con tooling genérico (Burp + crawler estático) no ven las rutas/API que solo aparecen tras hidratar. Es una ventaja real.
Confirmar impacto real antes de reportar — un triager rechaza "podría ser" sin evidencia. Screenshot, request/response completo, pasos numerados.
CVSS conservador y bien justificado — programas grandes tienen su propia rúbrica de severidad (a veces no es CVSS puro). Igual, verify_finding_severity ayuda a que la calificación interna que uses como referencia esté bien fundamentada antes de traducirla a la rúbrica del programa.

Fuerza bruta agresiva sin autorización explícita en el scope (rate limiting real puede tumbar el servicio de un tercero)
Reportar hallazgos de herramientas automáticas sin verificación manual (nuclei/nikto crudo, sin confirmar explotabilidad real) — exactamente lo que triage_findings está pensado para filtrar ANTES de que llegue a un reporte
Acceder a datos de OTROS usuarios más allá de lo mínimo para probar el IDOR/broken access control
Ingeniería social o phishing salvo que el programa lo permita explícitamente