Redacción de reportes que convierten

01Objetivo

Escribir reportes que el triage pueda validar en la primera lectura, sin ida y vuelta de aclaraciones — la diferencia real entre un hallazgo que cobra en días y uno que se eterniza o acaba en N/A por mala comunicación, no por mal hallazgo.

02Teoría

El reporte se escribe para quien lo va a rechazar si puede

Quien triagea un reporte suele tener decenas pendientes y un incentivo a cerrar rápido lo que no esté perfectamente claro. Un reporte ambiguo no recibe el beneficio de la duda: recibe un "necesito más información" que añade días, o directamente un N/A. El reporte debe eliminar toda ambigüedad posible, no asumir que el lector "ya lo entenderá".

Antes de escribir una sola línea: el filtro de las siete preguntas

Escribir un reporte completo para descubrir después que no era válido cuesta más que descartarlo a tiempo. Antes de abrir la plantilla, responde estas siete preguntas en orden — la primera respuesta negativa mata el hallazgo ahí mismo, sin seguir evaluando las demás:

1. ¿Puedo escribir la explotación como una petición HTTP real, paso a paso, ahora mismo? Si no puedes rellenar "necesito X cuenta/dato → mando esta petición exacta → obtengo este resultado exacto → el impacto real es Y", no está listo para reportar.
2. ¿El impacto está en la lista de categorías que el programa acepta? Revisa la policy (módulo 2): muchos programas excluyen por escrito categorías enteras aunque técnicamente "funcionen".
3. ¿La causa raíz está en un activo realmente dentro de scope, en producción (no en un entorno de prueba no cubierto) y no en infraestructura de un tercero que la empresa simplemente usa?
4. ¿Requiere un acceso privilegiado que un atacante real no podría conseguir? "Un admin puede hacer X" casi nunca es reportable — es un riesgo de centralización, no una vulnerabilidad. "Un usuario normal puede hacer lo que solo debería poder un admin" sí lo es.
5. ¿Es un comportamiento ya conocido o aceptado por diseño? Antes de reportar, busca si el propio programa ya lo documenta como intencionado o si aparece en reportes ya resueltos de la plataforma.
6. ¿Puedo demostrar el impacto más allá de "técnicamente posible"? Un XSS necesita robo de sesión real, no solo un alert(); un SSRF necesita alcanzar un endpoint interno real, no solo un ping DNS. Si solo puedes mostrar que algo es posible en teoría, baja la severidad — no mates el hallazgo, pero no lo infles.
7. ¿Es una clase de bug que ese programa nunca acepta? Revisa el histórico de "known issues" y exclusiones del módulo 2 antes de invertir tiempo redactando.

Este filtro no sustituye el criterio de los módulos anteriores, lo cierra: es la última comprobación antes de convertir horas de trabajo en un reporte que puede acabar en N/A por algo que se podía haber visto antes de escribir la primera palabra.

Estructura que funciona en la práctica

1. Título preciso con categoría e impacto, no genérico. "IDOR en /api/orders/{id} permite leer pedidos de otros usuarios" convierte mejor que "Problema de seguridad en API de pedidos".
2. Resumen de impacto en 2-3 líneas, al principio, antes de cualquier detalle técnico. Quien triagea decide en los primeros segundos si esto es severo; no lo hagas buscar esa respuesta entre párrafos.
3. Pasos de reproducción numerados, literales y mínimos. Cada paso debe ser ejecutable tal cual, sin que el lector tenga que inferir nada ("inicia sesión con cualquier cuenta" es peor que "inicia sesión con la cuenta de prueba A, usuario test_a@..."). Elimina cualquier paso que no sea estrictamente necesario para reproducir — pasos de más diluyen la claridad.
4. Petición y respuesta HTTP completas (request/response crudos del proxy), no una paráfrasis de lo que decían. El triage necesita poder repetir exactamente lo mismo.
5. Prueba de impacto concreta, no teórica: qué dato real (de una cuenta de prueba propia, nunca de un usuario real ajeno) quedó expuesto o modificado. "Esto podría permitir..." convierte mucho peor que "Esto permitió leer el campo X de la cuenta B creada para esta prueba".
6. CVSS propuesto con el vector completo, no solo la puntuación final — mostrar el vector (AV/AC/PR/UI/S/C/I/A) permite al triage auditar el cálculo en segundos en vez de tener que rehacerlo desde cero o cuestionarlo a ciegas.
7. Remediación sugerida, breve, orientada a causa raíz ("validar que el user_id del token coincide con el propietario del recurso antes de servir /api/orders/{id}"), no una recomendación genérica de "mejorar la seguridad".

Errores que hunden un buen hallazgo

• Mezclar varios hallazgos distintos en un solo reporte "para no escribir dos veces". Cada vulnerabilidad va en su propio reporte: facilita el triage y evita que un hallazgo débil arrastre a uno fuerte a la misma resolución.
• Capturas de pantalla en vez de petición/respuesta cruda. Una captura no se puede copiar y reproducir; el texto crudo sí.
• Lenguaje especulativo en la sección de impacto ("podría", "posiblemente", "en teoría"). Si no se puede demostrar con una prueba concreta, no se afirma como hecho.
• Asumir el contexto de negocio del lector. Explica brevemente por qué ese dato o esa acción es sensible para esa aplicación en concreto, no solo en abstracto.

03Caso real (anonimizado) — un reporte de principio a fin

Un reporte sobre un fallo de control de acceso en el programa de una plataforma europea de carpooling se estructuró así: título con categoría e impacto exactos; resumen de dos líneas indicando que un usuario autenticado podía leer datos de perfil de cualquier otro usuario mediante un identificador predecible en un endpoint de la API móvil; cinco pasos de reproducción literales usando dos cuentas de prueba creadas específicamente para el reporte; petición y respuesta HTTP crudas capturadas con Burp Suite mostrando el campo expuesto de la cuenta B; CVSS 3.1 con vector completo justificando "Alto" por confidencialidad sin necesidad de privilegios adicionales; y una línea de remediación apuntando a validar la pertenencia del recurso en el controlador del endpoint afectado. El resultado fue una validación de triage sin ninguna pregunta de aclaración — exactamente el resultado que busca esta estructura.

04Resumen operativo

1. Antes de escribir nada, pasa el hallazgo por el filtro de las siete preguntas — la primera respuesta negativa lo mata ahí, sin gastar tiempo redactando.
2. El resumen de impacto va primero, en dos o tres líneas, antes de cualquier detalle técnico.
3. Pasos de reproducción mínimos y literales, con petición/respuesta HTTP crudas, nunca capturas de pantalla como única prueba.
4. Un hallazgo por reporte, siempre. Nunca mezclar varios "para no repetir trabajo".
5. CVSS con vector completo, no solo número. Remediación orientada a causa raíz, no genérica.