Contenido del artículo
Un buen informe de pentest incluye un resumen ejecutivo breve, el alcance y las fechas de la prueba, la metodología y cada hallazgo con su criticidad, evidencia, pasos para reproducirlo, impacto en el negocio y cómo corregirlo. Cuando las correcciones están hechas, se añade el resultado del retest: qué está cerrado y qué no.
Abajo tienes el informe desglosado por secciones, una tabla de quién lee qué y qué debe aparecer, cómo se valora la criticidad, un ejemplo de hallazgo y las señales de un informe por el que no conviene pagar.
En resumen
- El resumen ejecutivo explica con palabras sencillas qué se encontró y qué supone para el negocio. Sin jerga.
- Alcance, fechas y limitaciones muestran qué se probó y qué no. Sin ellos no puedes enseñar el informe a un socio ni a un auditor.
- Cada hallazgo tiene título, criticidad, descripción, evidencia, pasos para reproducirlo, impacto y recomendación de corrección.
- La criticidad se suele puntuar con CVSS de FIRST y se ajusta al contexto de tu negocio.
- El retest confirma que las correcciones funcionan. Su resultado se añade al informe o se entrega como documento aparte.
- Una exportación del escáner con portada nueva no es un informe de pentest.
El informe por secciones: quién lo lee y qué debe aparecer
El informe lo leen personas distintas: la dirección decide tiempo y dinero, los desarrolladores corrigen, un auditor o un socio comprueba que la prueba se hizo. NIST dice claramente que un informe puede tener varias audiencias y que pueden hacer falta varios formatos para atenderlas. [2] PTES divide el informe en dos grandes partes: el resumen ejecutivo y el informe técnico. [3] La OWASP WSTG propone una estructura parecida: introducción con alcance y limitaciones, resumen ejecutivo, hallazgos y anexos. [4]
| Sección | Quién la lee | Qué debe contener | Señal de alarma si falta |
|---|---|---|---|
| Resumen ejecutivo | Propietario, CEO, CTO | Objetivo de la prueba, hallazgos clave en términos de negocio, estado general, acciones prioritarias | La dirección no sabe qué hacer y el informe acaba en un cajón |
| Alcance, fechas, limitaciones | CTO, auditor, socio | Sistemas, direcciones y roles probados, periodo de trabajo, qué no se probó y por qué | No puedes demostrar qué se probó |
| Metodología | CISO, auditor | Enfoque y estándares (OWASP WSTG, PTES, NIST SP 800-115), parte manual y automática | No queda claro si fue un pentest o una pasada de escáner |
| Tabla resumen de hallazgos | CTO, responsable de desarrollo | Número, título y criticidad de cada hallazgo | Cuesta planificar el trabajo y repartir tareas |
| Detalle de hallazgos | Desarrolladores, administradores | Descripción, evidencia, pasos para reproducir, impacto, recomendación, referencias | El equipo no puede reproducir el fallo y no se lo cree |
| Explicación de la valoración | CISO, auditor | Cómo se calculó la criticidad: CVSS, contexto de negocio | Los niveles parecen arbitrarios |
| Anexos | Equipo técnico | Salida de herramientas depurada, lista de pruebas realizadas | No hay rastro de que las pruebas se hicieran |
| Resultado del retest | Todos los que leyeron el informe | Estado de cada hallazgo tras las correcciones | Nadie sabe si las correcciones funcionaron |
La WSTG también recomienda una advertencia en la introducción: la prueba refleja un momento concreto y no garantiza que esté todo. [4] Es lo honesto: un pentest está limitado por alcance y tiempo.
Qué debe contener cada hallazgo
El hallazgo es la unidad básica del informe. Un desarrollador debe poder abrirlo y, sin llamar al tester, entender qué está roto, cómo comprobarlo y cómo corregirlo. La WSTG enumera estos campos: identificador, título, probabilidad o facilidad de explotación, impacto, nivel de riesgo, descripción, corrección y recursos adicionales. [4]
En la práctica, un buen hallazgo incluye:
- número y título breve que diga el problema: «Un cliente ve pedidos ajenos», no «Problema de autorización»;
- criticidad y, si se acordó, el vector CVSS;
- dónde exactamente: URL, parámetro, rol de usuario;
- descripción sencilla: qué falla y por qué es peligroso;
- evidencia: petición y respuesta, captura de pantalla, salida de un comando que muestre el resultado, con los datos sensibles enmascarados;
- pasos para reproducirlo que el desarrollador pueda seguir solo;
- impacto en el negocio: qué datos, dinero o procesos están en riesgo;
- recomendación: qué cambiar exactamente, no un genérico «actualice el sistema»;
- referencias: CWE, documentación, guía de corrección.
Ejemplo de un hallazgo bien redactado
El ejemplo es ficticio y solo muestra el formato.
| Campo | Contenido |
|---|---|
| Número y título | VT-03. Un cliente ve pedidos ajenos (IDOR) |
| Criticidad | Alta |
| Dónde | GET /orders/{id}, rol «cliente» |
| Descripción | El servidor no comprueba si el pedido pertenece al usuario que lo pide. Basta con cambiar el número en la URL. |
| Evidencia | El usuario A abre /orders/1045 (su pedido), cambia la URL a /orders/1046 y recibe una respuesta 200 con el nombre, el teléfono y la dirección de entrega del usuario B. Se adjuntan captura y petición, con los datos personales enmascarados. |
| Pasos para reproducir | 1. Entrar como el cliente de prueba A. 2. Abrir su propio pedido. 3. Cambiar el número de la URL por el siguiente. 4. Ver el pedido de otra persona. |
| Impacto | Cualquier cliente registrado puede descargar uno a uno los datos de todos los clientes. Es una fuga de datos personales y una pregunta del regulador para ti. |
| Recomendación | Comprobar en el servidor el propietario del pedido en cada petición. No confiar en que el número sea «difícil de adivinar». Añadir un test automático de acceso a objetos ajenos. |
| Referencias | CWE-639: Authorization Bypass Through User-Controlled Key |
| Retest | Corregido. La petición de un pedido ajeno devuelve 404. |
La diferencia entre un hallazgo así y una línea de escáner se explica en pentest o escaneo de vulnerabilidades.
Cómo se valora la criticidad
El sistema de puntuación más extendido es CVSS, que mantiene FIRST. La versión actual, CVSS v4.0, se publicó en noviembre de 2023. [1]
CVSS v4.0 tiene cuatro grupos de métricas: [1]
- Base: las cualidades propias de la vulnerabilidad, que no cambian con el tiempo ni entre entornos;
- Threat: lo que cambia con el tiempo, por ejemplo si existe un exploit funcional;
- Environmental: lo propio de tu entorno, por ejemplo los controles de seguridad;
- Supplemental: contexto adicional que no cambia la puntuación.
La puntuación de 0 a 10 se traduce en niveles: 0.1–3.9 baja, 4.0–6.9 media, 7.0–8.9 alta, 9.0–10.0 crítica. [1] La especificación pide completar la puntuación Base con las métricas de amenaza y de entorno. La Base por sí sola no describe el riesgo para tu empresa. [1]
Por eso un buen informe pone el contexto de negocio junto al CVSS. La misma vulnerabilidad en un entorno de pruebas sin datos y en un módulo de pagos tiene prioridades distintas. Un proveedor honesto explica por qué subió o bajó un nivel.
Una alternativa a CVSS es la OWASP Risk Rating Methodology. Calcula el riesgo a partir de la probabilidad y el impacto, cada uno en una escala de 0 a 9, con factores separados para el impacto técnico y el de negocio. [5] Sus autores dicen que el impacto en el negocio pesa más. [5] Los dos enfoques sirven. Lo importante es que el informe explique cómo se calculó.
Señales de un informe flojo
- Una exportación del escáner con otro nombre. Cientos de líneas de «posible vulnerabilidad», recomendaciones idénticas, ninguna verificación manual. Eso es un escaneo, no un pentest.
- Sin evidencias. El hallazgo se describe con palabras, pero no hay petición, respuesta ni captura. El equipo no puede confirmar que el problema existe.
- Sin pasos para reproducir. El desarrollador no puede repetir el fallo ni, después, comprobar su corrección.
- Todo es «crítico». Si todo arde, nadie sabe por dónde empezar. Los niveles deben variar y estar justificados.
- Sin alcance. No se sabe qué sistemas se probaron. Un informe así no demuestra nada a un socio ni a un auditor.
- Sin recomendaciones, o solo genéricas. «Siga las buenas prácticas» no es una tarea que alguien pueda coger.
- Sin retest. Sin una segunda comprobación nadie sabe si las correcciones funcionaron. NIST describe el retest como la forma de validar que las medidas de corrección se completaron. [2]
Qué hacer después con el informe
NIST recomienda que los informes internos incluyan la metodología, los resultados, el análisis y un plan de acción con pasos y plazos concretos. [2] Dicho de forma sencilla:
- Repasa el informe con el proveedor en una reunión mientras las dudas están frescas.
- Convierte los hallazgos en tareas con responsable y plazo, empezando por los críticos y altos.
- Corrige, comprueba por tu cuenta y luego pide el retest.
Cómo organizar ese trabajo se explica en después de un pentest: cómo corregir hallazgos y pasar el retest. Si todavía estás eligiendo proveedor, pide un informe de ejemplo anonimizado antes de firmar. Más preguntas en cómo elegir una empresa de pentesting.
Un informe de Veiltrack incluye un resumen ejecutivo, tablas de hallazgos por nivel de riesgo y, para cada hallazgo, su categoría, CWE, una puntuación CVSS 3.1 o 4.0 a elección del cliente, descripción técnica, evidencias y capturas, además del orden de corrección. Más en la página de pentest.
Lista de comprobación: revisa el informe antes de aceptarlo
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Qué debe incluir siempre un informe de pentest?
Resumen ejecutivo, alcance y fechas, metodología, tabla resumen de hallazgos y el detalle de cada uno: criticidad, evidencia, pasos para reproducirlo, impacto y recomendación. Tras las correcciones se añade el resultado del retest.
¿En qué se diferencia un informe de pentest de un informe de escáner?
El informe de escáner enumera posibles problemas sin verificación manual. En un informe de pentest cada hallazgo lo confirma una persona y tiene evidencia, pasos para reproducirlo y una explicación de lo que significa para ti.
¿Hay que usar CVSS obligatoriamente?
No. CVSS es lo más común, pero también sirven la OWASP Risk Rating Methodology o una escala propia. Lo importante es que el informe explique cómo se calcularon los niveles y tenga en cuenta tu negocio.
¿Quién debe leer el informe en la empresa?
La dirección lee el resumen para decidir recursos. Desarrolladores y administradores leen el detalle de los hallazgos para corregirlos. Un auditor o un socio revisa el alcance y la metodología.
¿Puedo enseñar el informe a un cliente o a un socio?
Sí, pero normalmente se comparte el resumen, el alcance y el estado del retest, no los detalles técnicos. El informe completo con los pasos para reproducir solo va a quien lo necesita para trabajar.
Referencias
- FIRST: CVSS v4.0 Specification Document first.org
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
- PTES Technical Guidelines: Reporting pentest-standard.readthedocs.io
- OWASP WSTG: Reporting Structure wstg.owasp.org
- OWASP Risk Rating Methodology community.owasp.org
