Escribir reportes de bug bounty con IA

Un bug no vale nada hasta que otra persona puede reproducirlo y ver el impacto. El reporte es donde eso pasa, y es el paso que el principiante apura. Un modelo redacta un reporte limpio desde tus notas en segundos, lo cual es útil, siempre que confirmes cada línea antes de que salga. Este post cierra la serie que empezó con el loop. Para lo básico de escribir reportes, cómo escribir tu primer reporte de seguridad combina bien con esto.

#Qué necesita un triager

Un triager lee muchos reportes y reproduce los que son claros. Dale un título corto que nombre el bug y el activo, pasos exactos que pueda seguir, el request y la response que lo prueban, y una declaración simple de impacto. Haz que pueda pegar tus pasos y ver el mismo resultado. Un reporte que hace adivinar al lector queda cerrado o vuelve por más detalle.

#Las partes de un reporte

Parte	Lo que va en ella
Título	La clase de bug y el activo afectado
Resumen	Una o dos frases sobre qué es y por qué importa
Pasos	Numerados, exactos, reproducibles desde un estado limpio
Evidencia	El request y la response, capturas donde ayuden
Impacto	Lo que gana un atacante, dicho con claridad
Fix	Una sugerencia corta y honesta cuando tienes una

#Redacta desde tus notas con el modelo

Si llevaste notas por el loop, tienes la materia prima. Dale al modelo el request, la response y lo que el bug le deja hacer a un atacante, y pide un reporte con la estructura de arriba. El modelo es bueno en volver notas crudas en prosa limpia y pasos consistentes. Dale hechos, no una conjetura sobre severidad, y dile que deje un placeholder donde le falte un detalle, para que escriba un hueco en vez de inventar uno.

#Califica la severidad con honestidad

La severidad decide el tramo de recompensa, así que la tentación de inflarla es real, y los triagers la ven venir rápido. Califica lo que probaste, no lo que podría ser posible. La Bugcrowd Vulnerability Rating Taxonomy mapea clases de bug a severidades, y CVSS de FIRST da un puntaje con un vector documentado. Un modelo puede proponer un vector CVSS, y tú chequeas cada métrica contra lo que de verdad demostraste. Un medium honesto gana a un high exagerado que te bajan y te marca como alguien que exagera.

#Confirma cada línea antes de enviar

Esta es la misma regla sobre la que corre toda la serie. Lee el borrador del modelo contra tu evidencia. ¿Funciona cada paso desde un estado limpio? ¿Está correcta cada URL y cada parámetro? ¿El impacto coincide con lo que probaste, sin nada agregado para el efecto? Recorre tus propios pasos una vez más sobre el objetivo, exactamente como están escritos, y corrige cualquier cosa que no se reproduzca. El reporte tiene que ser verdad, porque el triager lo va a correr.

#Qué no dejar que haga el modelo

No dejes que el modelo escriba impacto que no puede sostener, nombre un CVE del que no está seguro ni describa un paso que no hiciste. Estos son los errores que un modelo fluido comete al tratar de ser útil, y cada uno te cuesta credibilidad con el programa. Mantén los datos de programa y de usuario fuera del borrador más allá del mínimo necesario para mostrar el bug, y mantén el reporte fuera de servicios públicos hasta que el programa haya arreglado el problema y acordado la divulgación. Los términos de disclose.io describen la divulgación de buena fe.

#Envía, y luego haz seguimiento

Manda el reporte por el canal del programa, responde preguntas rápido y suma detalle si el triager lo pide. Si bajan el bug, lee por qué antes de discutir, porque el triager suele tener contexto que tú no. Un seguimiento calmo y preciso construye el historial que gana invitaciones privadas después.

#El fin de la serie, y el comienzo del loop

Leíste un scope, mapeaste una superficie, probaste y confirmaste bugs, armaste un agente para acelerar las partes aburridas y escribiste un reporte. Ese es el loop entero. Córrelo otra vez en el siguiente activo. Mantén abiertas la OWASP Web Security Testing Guide y el caso de uso de bug bounty, y empieza la siguiente pasada desde el loop.