Reporte de pentesting profesional: guía

Respuesta directa: Un reporte de pentesting de calidad contiene cinco secciones obligatorias: resumen ejecutivo dirigido a liderazgo no técnico, sección de metodología con referencia al estándar seguido (PTES, OWASP WSTG, NIST SP 800-115), hallazgos individuales con clasificación CVSS v3.1, evidencia reproducible (capturas de pantalla y solicitud/respuesta HTTP), y una sección de remediación con verificación. Un reporte que solo es una lista de salidas de herramientas automatizadas no es un reporte de pentesting: es un reporte de escaneo.

Por qué el reporte es el producto del pentest

El valor de un pentest no está en el proceso: está en los hallazgos documentados y en la capacidad del cliente para actuar sobre ellos. Un equipo de pentest brillante que entrega un reporte confuso, incompleto o no accionable ha desperdiciado el presupuesto del cliente tanto como si no hubiera ejecutado las pruebas.

El reporte es también el artefacto que el cliente presentará a su junta directiva, a su equipo de auditoría, a reguladores o a clientes empresariales que exigen evidencia de sus controles de seguridad. Un reporte de baja calidad no solo es inútil técnicamente — puede ser contraproducente si el cliente lo usa en contextos de compliance.

La norma de facto para reportes de pentesting en la industria está documentada en el Penetration Testing Execution Standard (PTES) y en el NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment). Ambos especifican qué debe contener un reporte profesional. A continuación, una guía práctica de lo que deberías recibir.

Sección 1: Resumen Ejecutivo

El resumen ejecutivo está diseñado para una audiencia que no es técnica: el CEO, la junta directiva, el Chief Risk Officer. Debe responder tres preguntas en no más de dos páginas:

¿Cuál es el estado general de seguridad de lo evaluado? Una valoración cualitativa (crítico, alto riesgo, riesgo moderado, controlado) con una oración que explique el razonamiento. No un promedio de scores CVSS — una evaluación profesional de la postura de seguridad global.

¿Cuáles son los hallazgos de mayor impacto potencial para el negocio? Los dos o tres hallazgos que más le importan a alguien que toma decisiones presupuestarias: no los más técnicamente interesantes, sino los que representan mayor riesgo para la continuidad del negocio, la reputación o el cumplimiento regulatorio.

¿Qué debe hacerse primero? Una priorización clara de acciones de remediación, sin tecnicismos, con estimaciones de esfuerzo cuando sea posible.

Un resumen ejecutivo que el CEO no puede leer y entender en 10 minutos no cumple su función. Muchos reportes de baja calidad simplemente omiten esta sección o pegan en ella el índice de hallazgos con scores CVSS — eso no es un resumen ejecutivo.

Sección 2: Metodología

La sección de metodología documenta qué se hizo, con qué herramientas, y durante cuánto tiempo. Sirve para dos propósitos: da trazabilidad al cliente sobre cómo se obtuvieron los hallazgos, y permite comparar el alcance real de la evaluación con el scope acordado.

Un reporte de calidad debe incluir:

Estándar seguido: Referencia explícita al marco metodológico utilizado: OWASP Web Security Testing Guide (WSTG v4.2) para aplicaciones web, OWASP API Security Top 10 2023 para APIs, PTES para pentests de infraestructura, o NIST SP 800-115 para evaluaciones en contextos gubernamentales.

Período de evaluación: Fechas exactas de inicio y fin de las pruebas. Esto permite al cliente contextualizar los hallazgos: si se hizo un deploy importante después del pentest, los hallazgos pueden ya no ser representativos.

Herramientas utilizadas: Lista de las principales herramientas, tanto automatizadas (Burp Suite Pro, Nessus, Nmap, OWASP ZAP, Metasploit) como técnicas manuales. Esto ayuda al cliente a entender si la evaluación fue principalmente automatizada o genuinamente manual.

Alcance cubierto vs acordado: Si el scope original incluía 15 aplicaciones y solo 12 fueron evaluadas, el reporte debe explicar por qué las 3 restantes no fueron cubiertas. Sin esta información, el cliente puede asumir cobertura completa cuando no la tuvo. Un scope bien definido desde el inicio es fundamental: si aún no has preparado la documentación previa al pentest, consulta la guía sobre cómo preparar a tu empresa para un pentest.

Tipo de pentest: Black box (sin información previa), gray box (con credenciales y documentación parcial) o white box (con acceso completo a código fuente y arquitectura). El tipo de pentest determina qué tan exhaustivos pueden ser los resultados.

Sección 3: Hallazgos individuales

Esta es la sección técnica central del reporte. Cada hallazgo debe contener los siguientes elementos:

Título y clasificación de severidad (CVSS v3.1)

El Common Vulnerability Scoring System versión 3.1 es el estándar de la industria para clasificar vulnerabilidades. Un score CVSS se calcula a partir de métricas base (vector de ataque, complejidad, privilegios requeridos, impacto en confidencialidad/integridad/disponibilidad) y produce un número entre 0 y 10 con una clasificación cualitativa:

Rango CVSS v3.1	Severidad
9.0 – 10.0	Crítica
7.0 – 8.9	Alta
4.0 – 6.9	Media
0.1 – 3.9	Baja
0.0	Informativa

El vector CVSS debe estar incluido explícitamente en el reporte (por ejemplo: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), no solo el número. El vector permite al cliente calcular su propio score si tiene métricas temporales o ambientales que modifican el riesgo en su contexto específico.

Adicionalmente, cada hallazgo debe incluir el CWE (Common Weakness Enumeration) relevante. Por ejemplo, una inyección SQL se traza a CWE-89; un IDOR a CWE-639. Esto facilita la búsqueda de referencias técnicas y la comunicación con el equipo de desarrollo.

Descripción técnica

Una explicación clara de la vulnerabilidad: qué es, por qué existe, y por qué es un riesgo. Dirigida al equipo técnico que deberá remediarla. No debe ser una copia de Wikipedia del CWE — debe estar contextualizada a la aplicación específica que se evaluó.

Pasos de reproducción

Las instrucciones paso a paso que permiten al equipo de desarrollo reproducir la vulnerabilidad de forma independiente. Esto es crítico: si el equipo de desarrollo no puede reproducir el hallazgo, no puede verificar que la remediación fue efectiva.

Los pasos deben ser suficientemente detallados para que alguien que no estuvo en el pentest pueda reproducirlos. Un hallazgo que dice "el parámetro ID es vulnerable a IDOR" sin explicar cómo demostrarlo no es accionable.

Evidencia

Todo hallazgo debe estar respaldado por evidencia que demuestre la vulnerabilidad:

Capturas de pantalla: Muestran el estado de la aplicación antes y después de la explotación. Deben estar anotadas para señalar exactamente qué es relevante en cada imagen.

Solicitud y respuesta HTTP (raw): Para vulnerabilidades en aplicaciones web y APIs, la solicitud HTTP exacta que demostró la vulnerabilidad (con headers relevantes) y la respuesta del servidor que confirma la explotabilidad. Esta evidencia es la más valiosa para el equipo de desarrollo porque permite entender exactamente qué parámetro, qué endpoint y qué payload fue el vector.

Salida de herramientas cuando es relevante: Para vulnerabilidades de criptografía, configuración de TLS, o escaneo de puertos, la salida cruda de herramientas como sslyze, nmap o testssl.sh añade credibilidad técnica y contexto adicional.

Impacto en el negocio

No solo el score CVSS — una descripción de qué podría hacer un atacante si explotara esta vulnerabilidad: acceder a datos de clientes, tomar control de cuentas, escalar privilegios al nivel de administrador, exfiltrar la base de datos completa. Conectar el hallazgo técnico con su impacto de negocio es lo que permite a los equipos priorizar remediaciones con criterio de riesgo real.

Recomendación de remediación

Instrucciones específicas para corregir la vulnerabilidad, adaptadas al stack tecnológico de la aplicación evaluada. "Sanitizar inputs" no es una recomendación útil. "Utilizar consultas parametrizadas con PDO en PHP o PreparedStatement en Java, y validar el tipo de dato del parámetro user_id antes de usarlo en la consulta" sí lo es.

Las referencias a estándares de remediación añaden valor: OWASP Cheat Sheet Series, NIST guidelines, CWE mitigation guidance.

Sección 4: Verificación de remediaciones (retests)

Esta sección existe en los mejores reportes y está ausente en los más comunes. Documenta el proceso de verificación de que los hallazgos fueron corregidos de forma efectiva.

Un ciclo completo de retest incluye:

El cliente implementa la remediación del hallazgo
El pentester ejecuta los mismos pasos de reproducción contra el entorno corregido
El resultado se documenta: la vulnerabilidad fue corregida, fue corregida parcialmente, o el fix introdujo un nuevo problema
El hallazgo se cierra con evidencia documentada del estado post-remediación

Para entender por qué los retests son parte intrínseca del proceso y no un extra opcional, consulta el artículo sobre reportes automatizados vs reportes manuales de pentesting y cómo los mejores proveedores gestionan este ciclo. Los mejores proveedores incluyen retests sin límite en el contrato. El cliente puede solicitar verificación de cada hallazgo individualmente a medida que va implementando correcciones — no necesita esperar a tener todas las remediaciones listas para solicitar el retest.

Red flags: señales de un reporte de baja calidad

Señales inequívocas de que el reporte no fue ejecutado con rigor

Sin resumen ejecutivo, o con uno que es una lista de bullets con scores CVSS
Sin metodología documentada: no se especifica qué estándar se siguió ni qué herramientas se usaron
Hallazgos sin evidencia: "Se detectó SQL Injection en el parámetro X" sin captura de pantalla ni request/response
CVSS sin vector: solo el número (7.8) sin el vector que lo justifica
Recomendaciones genéricas: "Implementar validación de inputs" sin contexto del stack tecnológico
Sin CWE ni CVE: los hallazgos no están trazados a estándares conocidos
Fecha única en el reporte: un reporte sin fechas de inicio y fin del período de evaluación
Solo hallazgos de severidad media y baja: improbable en cualquier aplicación real; sugiere que el pentest fue superficial o que las pruebas se ejecutaron contra un entorno diferente al de producción
Output de herramienta sin análisis: páginas de salida de Nessus o Burp Scanner sin interpretación humana

Señales de que el reporte es un escaneo automatizado con marca cambiada

El test más simple: busca en el reporte la palabra "plugin" o "check ID". Si aparece, estás leyendo la salida de una herramienta de escaneo (Nessus, Qualys) con el logo del proveedor encima. Eso es una evaluación de vulnerabilidades, no un pentest.

Cómo verificar la calidad de un reporte que ya tienes

Si ya tienes un reporte de un proveedor anterior y quieres evaluar su calidad, estas son las preguntas que debes hacerte:

¿Puedo reproducir el primer hallazgo siguiendo los pasos descritos? Toma el hallazgo de mayor severidad e intenta reproducirlo con las instrucciones del reporte. Si no puedes, el reporte no es suficientemente detallado.
¿El resumen ejecutivo describe el riesgo en términos de negocio? Si menciona "CVEs", "payloads" o "vectores de ataque" sin explicar su impacto al negocio, no está dirigido a la audiencia correcta.
¿Existen hallazgos de todas las severidades? Un reporte con 47 hallazgos de severidad baja y ninguno de severidad alta en una aplicación de e-commerce es estadísticamente improbable y sugiere que las pruebas no cubrieron los vectores de mayor riesgo.
¿El período de evaluación está documentado? Sin fechas, no puedes saber si el reporte es relevante para el estado actual de tu aplicación.

Preguntas frecuentes

¿Qué debe incluir un buen reporte de pentesting?

Un reporte de pentesting de calidad incluye cinco secciones obligatorias: resumen ejecutivo para liderazgo no técnico, metodología con referencia al estándar seguido (PTES, OWASP WSTG o NIST SP 800-115), hallazgos individuales con CVSS v3.1 y vector completo, evidencia reproducible (capturas de pantalla y solicitud/respuesta HTTP por hallazgo) y una sección de remediación verificada mediante retests. Un reporte que solo contiene salidas de herramientas automáticas sin análisis humano no es un reporte de pentesting profesional.

¿Cómo se califica la severidad de las vulnerabilidades en un reporte?

La severidad se califica con CVSS v3.1 (Common Vulnerability Scoring System), que produce un score de 0 a 10 basado en métricas objetivas: vector de ataque, complejidad, privilegios requeridos e impacto en confidencialidad, integridad y disponibilidad. Los rangos son: Crítica (9.0–10.0), Alta (7.0–8.9), Media (4.0–6.9) y Baja (0.1–3.9). Un reporte profesional incluye el vector completo, no solo el número, para que el cliente pueda ajustar el score según su contexto ambiental específico.

¿Qué es el CVSS y cómo se usa en los reportes de pentesting?

CVSS (Common Vulnerability Scoring System) es el estándar de la industria para cuantificar la severidad de vulnerabilidades. En los reportes de pentesting se usa para clasificar cada hallazgo con un número entre 0 y 10 y un vector que documenta las métricas utilizadas. El vector completo — por ejemplo CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — permite al cliente recalcular el score ajustando factores ambientales de su infraestructura, algo que el número solo no permite hacer.

Un reporte de pentesting de calidad no es un deliverable de compliance: es una herramienta de trabajo. El equipo de desarrollo debe poder abrirlo y comenzar a trabajar en las remediaciones el mismo día que lo recibe.

Algunos proveedores, como WhiteJaguars, optan por entregar los hallazgos a través de una plataforma SaaS con acceso en tiempo real — no como PDFs estáticos enviados al final del engagement. Esto permite que el equipo cliente vea cada hallazgo con CVSS v3.1, CWE, evidencia reproducible e integración con herramientas de tickets como Jira o GitHub Issues, desde el primer día del pentest, no al cierre. Es un criterio concreto y verificable a evaluar al comparar proveedores.

Cómo se ve un buen reporte de pentesting (y cómo verificarlo)