Un informe de pentesting con ochenta hallazgos no es peor que otro con doce. Puede ser mejor, o mucho peor: todo depende de qué hallazgos son, cuáles son explotables de verdad y cuánto daño harían en tu negocio. El error más caro que comete un comité al recibir un informe es leer el número total y no la explotabilidad real.
Este artículo explica cómo leer un informe de pentesting como un decisor: qué debe contener, cómo interpretar la severidad, por qué el CVSS no es toda la historia y cómo priorizar la remediación de lo que de verdad importa. Cierra la serie junto a nuestros artículos sobre herramientas y metodologías de pentesting.
Anatomía de un buen informe
Un informe útil no es un listado de vulnerabilidades. Tiene un resumen para dirección en lenguaje de negocio, el alcance exacto de lo probado (y lo que quedó fuera), la metodología seguida y, por cada hallazgo, una descripción, la evidencia que lo reproduce, una severidad justificada y una recomendación de remediación concreta. Si falta la reproducción o la remediación, no es un informe: es una lista.
La primera señal de calidad es honesta y sencilla: ¿el proveedor distingue lo que probó de lo que no pudo probar? Un buen informe declara sus límites. Un mal informe finge cobertura total.
Severidad: el CVSS no es toda la historia
La mayoría de los informes puntúan la severidad con CVSS, hoy en su versión 4.0. El problema es leer solo la puntuación base. El CVSS v4.0 distingue explícitamente la base (CVSS-B) de las métricas de amenaza y de entorno (CVSS-BT, CVSS-BE, CVSS-BTE), y precisamente esas últimas —la exposición y el impacto en TU entorno— son las que convierten un 9,8 teórico en un riesgo alto o irrelevante para ti. Un CVSS base alto en un sistema aislado sin datos puede importar menos que un CVSS medio en tu pasarela de pago.
Priorizar por explotabilidad real: EPSS, KEV y contexto
La severidad técnica es solo una de las señales. Para decidir qué remediar primero conviene cruzarla con la probabilidad de explotación y con la explotación observada en el mundo real. Es el enfoque que ya defendemos en KEV, EPSS y SSVC y que un buen informe debería facilitarte.
| Señal | Qué indica | Fuente |
|---|---|---|
| CVSS v4.0 (base) | Gravedad técnica intrínseca del fallo | FIRST |
| EPSS | Probabilidad de explotación en los próximos 30 días | FIRST |
| CISA KEV | Explotación confirmada en el mundo real | CISA |
| Contexto de entorno | Exposición e impacto real en tu negocio | Criterio propio |
Ninguna señal decide sola. La prioridad nace de cruzar gravedad, probabilidad, explotación real y contexto.
El EPSS estima la probabilidad de que un fallo se explote en los próximos treinta días; el catálogo KEV de CISA confirma qué se está explotando ya. Un hallazgo con CVSS medio pero presente en KEV puede merecer más urgencia que un CVSS crítico sin explotación conocida y sin exposición en tu entorno. Priorizar es cruzar señales, no ordenar por una columna.
Falsos positivos y falsos negativos
Un informe generado solo con escáner llega lleno de falsos positivos: hallazgos que no son explotables en tu contexto y que consumen tiempo del equipo. Peor son los falsos negativos: lo que el escáner no vio. Los abusos de lógica de negocio —una porción relevante de los hallazgos críticos reales— no aparecen en pruebas automáticas, así que un informe sin hallazgos de lógica probablemente no es un informe limpio, sino un informe superficial.
Por eso cada hallazgo relevante debe venir con evidencia reproducible. Si no puedes reproducir el paso, no puedes verificar la remediación ni defender la decisión ante un auditor.
De hallazgo a remediación: el ciclo no acaba en el PDF
El valor de un pentest no está en el informe, sino en lo que cambias después. Eso exige convertir cada hallazgo en una acción con responsable y plazo, integrarlo en tu gestión de vulnerabilidades y cerrar el ciclo con un retest que confirme que la corrección funciona. Un hallazgo «corregido» sin retest es una suposición, no un control.
Priorizar la remediación con criterio de riesgo real —no por el color del hallazgo— es lo que separa un plan ejecutable de una lista imposible. Lo desarrollamos en gestión de vulnerabilidades: priorizar riesgo real.
Qué exige la norma sobre las pruebas y su evidencia
El informe no es solo un entregable técnico: en entornos regulados es evidencia. PCI DSS 4.0.1 exige conservar los informes de intrusión y repetir la prueba tras cambios significativos; DORA requiere una atestación formal del TLPT —bajo el marco TIBER-EU— para las entidades significativas; NIS2 obliga a demostrar que se evalúa la eficacia de las medidas; y el ENS pide pruebas de penetración documentadas para categorías media y alta. En todos los casos, un informe sin evidencia reproducible y sin retest vale poco ante un auditor.
Lo esencial
Leer bien un informe de pentesting es dejar de contar hallazgos y empezar a evaluar riesgo. Mira si cada hallazgo se reproduce, cruza la severidad con la probabilidad y la explotación real, desconfía de un informe sin fallos de lógica y exige siempre un retest. El pentest no termina cuando llega el PDF: termina cuando has cambiado lo que ese PDF señaló.