Escribir un buen reporte

El reporte es tu producto: por muy buen bug que encuentres, si el equipo no lo entiende o no puede reproducirlo, no cobras. Un reporte claro, reproducible y con el impacto bien argumentado acelera el triaje, maximiza la recompensa y construye tu reputación.

Estructura de un buen reporte

Título       claro y específico ("IDOR en /api/users/{id} permite leer datos de otros")
Resumen      qué es, dónde, y el IMPACTO en una frase (para el triaje)
Pasos        reproducción NUMERADA y exacta (requests, cuentas, valores)
PoC          prueba de concepto reproducible (capturas, request/response, vídeo si ayuda)
Impacto      qué consigue un atacante y por qué importa al NEGOCIO
Severidad    CVSS + razonamiento; alinear con la taxonomía del programa (VRT)
Remediación  cómo arreglarlo (demuestra que entiendes el bug)

Reproducibilidad (lo nº1)

- pasos EXACTOS: URLs, métodos, cabeceras, cuerpos, cuentas usadas (A y B para IDOR)
- valores concretos, no "cambia el id por otro" -> "cambia 1337 por 1338"
- entorno/precondiciones (logueado como X, feature activada)
- si el triager no lo reproduce en 2 minutos, se ralentiza o se cierra

Argumentar el impacto y la severidad

- traducir el bug a RIESGO DE NEGOCIO: "acceso a datos de todos los usuarios" > "IDOR"
- CVSS como lenguaje común, pero explica el vector; no inflar (pierdes credibilidad)
- demostrar el PEOR caso realista (no teórico imposible): encadenar si aumenta impacto
- alinear con la tabla/VRT del programa (bb-plataformas)

Encadenar bugs

- varios bugs de baja severidad encadenados pueden ser CRÍTICOS (p. ej. info leak + IDOR + CSRF)
- reportar la CADENA con el impacto final, dejando claro cada eslabón
- esto es lo mejor pagado y lo que te distingue

Comunicación y triaje

- tono profesional y respetuoso; el triager es tu aliado, no tu rival
- responder rápido a preguntas; aportar más PoC si lo piden
- si discrepas en severidad/duplicado, argumenta con DATOS, sin faltar
- no divulgar públicamente sin permiso (romper disclosure = baneo)

Blue Team / nota

Un reporte vale lo que su reproducibilidad: pasos exactos > prosa vaga.
Traducir el bug a riesgo de negocio maximiza severidad y recompensa.
Encadenar bugs de bajo impacto a uno crítico es el mayor diferenciador.
Comunicación profesional: el triager es aliado; nada de divulgación sin permiso.

Buenas prácticas y errores comunes

Haz el bug reproducible: pasos exactos, PoC mínima, impacto claro; un reporte confuso se rechaza aunque sea válido.
Explica el impacto de negocio, no solo la vuln técnica; justifica así una severidad (y un pago) mayor.
Error típico: exagerar la severidad o incluir datos reales exfiltrados; demuestra con PoC mínima y sin dañar.

Checklist de prueba

Título claro y específico con el impacto
Resumen con qué/dónde/impacto en una frase
Pasos de reproducción numerados y EXACTOS
PoC reproducible (requests/capturas/vídeo)
Impacto traducido a riesgo de negocio
Severidad CVSS alineada con la VRT del programa
Remediación propuesta
Comunicación profesional; sin divulgación no autorizada