El informe de pentest es lo único que queda cuando los testers se van. Los exploits, las shells a la madrugada y las cadenas ingeniosas solo sirven si terminan en un documento que los ejecutivos entiendan, que los developers puedan accionar y que un auditor acepte como evidencia. Un informe flojo convierte un buen pentest en un PDF que nadie lee.
En esta guía tenés una plantilla de informe de pentest completa para copiar, qué va en cada sección, un hallazgo de ejemplo escrito de punta a punta y consejos para escribir el mismo informe para dos lectores muy distintos: ejecutivos y developers.
Para qué sirve un informe de pentesting
Un pentest es un ataque autorizado, con tiempo acotado, contra un alcance definido. El informe tiene cuatro trabajos:
- Informar decisiones. La dirección necesita saber qué tan expuesta está la empresa y cuánto cuesta arreglarlo.
- Habilitar correcciones. Los developers necesitan detalle suficiente para reproducir cada problema sin llamar al tester.
- Aportar evidencia. Clientes, auditores y marcos como SOC 2, ISO 27001 o PCI DSS suelen pedir un informe reciente y prueba de remediación.
- Crear una línea base. El pentest del año que viene se compara contra este.
Si una sección no cumple ninguno de esos trabajos, sacala. Las páginas de output de herramientas pegadas como anexo casi nunca ayudan a nadie.
La estructura de un buen informe de pentest
| Sección | Lector principal | Qué responde |
|---|---|---|
| Resumen ejecutivo | CEO, CTO, directorio, clientes | Qué tan grave es, qué importa más, qué hacemos |
| Alcance y reglas de compromiso | Todos, auditores | Qué se probó, cuándo, desde dónde y qué quedó afuera |
| Metodología | Equipo de seguridad, auditores | Cómo se hizo la prueba y contra qué estándar |
| Resumen de hallazgos | Líderes de ingeniería | La lista completa, ordenada por severidad |
| Hallazgos detallados | Developers | Cómo reproducir, por qué importa, cómo corregir |
| Rating de riesgo | Dirección, seguridad | La postura general en una frase |
| Retest | Auditores, clientes | Qué se verificó como corregido y cuándo |
Plantilla de informe de pentest gratis (para copiar y pegar)
Copiá este bloque en tu editor de documentos o en un repo con Markdown y reemplazá lo que está entre corchetes.
INFORME DE PENETRATION TEST
Cliente: [Nombre de la empresa]
Aplicación / entorno: [Nombre, versión, URL o repositorio]
Ventana de prueba: [Fecha de inicio] a [Fecha de fin]
Versión del informe: [1.0] Fecha: [Fecha] Clasificación: [Confidencial]
Elaborado por: [Tester, certificaciones] Revisado por: [Revisor de QA]
1. RESUMEN EJECUTIVO
1.1 Objetivo: [Por qué se hizo: pedido de cliente, release, auditoría]
1.2 Rating de riesgo general: [Critical / High / Medium / Low]
1.3 Resultados clave:
- [N] hallazgos: [x] Critical, [x] High, [x] Medium, [x] Low, [x] Informativos
- Riesgo más importante: [Una frase en términos de negocio]
- Fortalezas observadas: [Lo que estaba bien hecho]
1.4 Recomendaciones principales:
1. [Acción, responsable, plazo sugerido]
2. [Acción, responsable, plazo sugerido]
3. [Acción, responsable, plazo sugerido]
2. ALCANCE Y REGLAS DE COMPROMISO
2.1 Dentro del alcance: [URLs, rangos de IP, APIs, repositorios, apps móviles]
2.2 Fuera del alcance: [Servicios de terceros, cambios en datos productivos, DoS]
2.3 Tipo de prueba: [Black box / grey box / white box]
2.4 Cuentas provistas: [Roles y cantidad de usuarios de prueba]
2.5 IPs de origen de los testers: [IPs]
2.6 Restricciones y limitaciones: [Tiempo, funciones no disponibles, pruebas bloqueadas]
3. METODOLOGÍA
3.1 Estándares seguidos: [PTES, OWASP WSTG, NIST SP 800-115]
3.2 Fases: reconocimiento, mapeo, descubrimiento de vulnerabilidades,
explotación, post-explotación, reporte
3.3 Herramientas usadas: [Lista]
3.4 Modelo de severidad: score base CVSS [v3.1 / v4.0] más contexto de negocio
None 0.0 | Low 0.1-3.9 | Medium 4.0-6.9 | High 7.0-8.9 | Critical 9.0-10.0
4. RESUMEN DE HALLAZGOS
| ID | Título | Severidad | CVSS | CWE | Activo | Estado |
|--------|-------------------------|-----------|------|---------|-----------------|---------|
| PT-01 | [Título] | [High] | [x.x]| [CWE-x] | [Endpoint/archivo]| Abierto |
| PT-02 | [Título] | [Medium] | [x.x]| [CWE-x] | [Endpoint/archivo]| Abierto |
5. HALLAZGOS DETALLADOS
ID: [PT-01]
Título: [Corto y específico]
Severidad: [High] CVSS: [score] ([vector]) CWE: [CWE-x: nombre]
Activo afectado: [URL, parámetro, archivo y línea]
Descripción: [Qué es la vulnerabilidad]
Pasos para reproducir:
1. [Paso]
2. [Paso]
Evidencia: [Request/response, referencia a captura, datos redactados]
Impacto: [Qué puede hacer un atacante, en términos de negocio]
Remediación: [Corrección concreta, con ejemplo de código o configuración]
Referencias: [OWASP, CWE, documentación del proveedor]
Estado: [Abierto / Corregido / Riesgo aceptado]
6. RATING DE RIESGO GENERAL
[Rating] porque [motivos principales]. Probabilidad: [x]. Impacto: [x].
7. RETEST
Fecha del retest: [Fecha]
| ID | Severidad original | Resultado del retest | Evidencia |
|-------|--------------------|-------------------------|--------------|
| PT-01 | High | Corregido | [Referencia] |
| PT-02 | Medium | Parcialmente corregido | [Referencia] |
ANEXOS
A. Cuentas de prueba y datos creados (y eliminados)
B. Glosario para lectores no técnicosSección por sección: qué escribir
Resumen ejecutivo
Una página, como máximo. Nada de payloads ni headers HTTP. Poné el objetivo, el rating general, la cantidad de hallazgos por severidad, el riesgo o los dos riesgos que de verdad importan en lenguaje de negocio y las tres acciones principales. "Un cliente logueado puede descargar las facturas de cualquier otro cliente, con nombres, direcciones y montos" es mucho mejor que "IDOR en la API de facturas".
Alcance y reglas de compromiso
Es la sección que protege a las dos partes. Listá exactamente qué se probó y qué no, las fechas, el tipo de prueba (black, grey o white box) y cualquier limitación. Si el panel de admin estuvo caído dos de los cinco días, escribilo. Un auditor que lee "se probó toda la aplicación" cuando la mitad no estaba accesible no va a confiar en el resto.
Metodología
Nombrá el estándar que seguiste: PTES (Penetration Testing Execution Standard), la OWASP Web Security Testing Guide (WSTG) o NIST SP 800-115. Mapear los hallazgos al OWASP Top 10 también ayuda a ubicar cada problema. Mencioná las herramientas principales, pero acordate de que el informe es sobre resultados, no un catálogo de herramientas de pentesting.
Hallazgos: severidad, CVSS y CWE
Cada hallazgo necesita una severidad comparable. Lo habitual es CVSS, el Common Vulnerability Scoring System que mantiene FIRST. CVSS v4.0 se publicó el 1 de noviembre de 2023 y la v3.1 se sigue usando muchísimo. Las dos comparten las mismas bandas cualitativas: None 0.0, Low 0.1 a 3.9, Medium 4.0 a 6.9, High 7.0 a 8.9, Critical 9.0 a 10.0. Indicá siempre la versión y el vector completo, no solo el número, para que cualquiera pueda recalcularlo.
Sumá un identificador CWE (Common Weakness Enumeration, que mantiene MITRE). El CWE le dice al developer qué clase de bug es, lo lleva a guías de prevención y te permite seguir debilidades que se repiten entre informes.
Rating de riesgo y retest
El rating general es un juicio, no un promedio. Un solo Critical en un flujo de pagos expuesto a internet hace que el rating sea Critical aunque todo lo demás sea Low. El retest registra, para cada hallazgo, si la corrección se verificó, con fecha y evidencia. Cuando un cliente te pide "el último pentest", casi siempre quiere ver esta sección.
Ejemplo de hallazgo, escrito completo
Así se ve un hallazgo completo en la práctica. Es una vulnerabilidad IDOR, uno de los problemas más comunes en apps web y APIs modernas.
ID: PT-03
Título: Cualquier usuario logueado puede leer facturas de otros clientes
Severidad: Medium
CVSS v3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-639 Authorization Bypass Through User-Controlled Key
Activo afectado: GET /api/invoices/:id
src/routes/invoices.js, línea 42
Descripción:
El endpoint carga una factura por su ID numérico y la devuelve a
cualquier usuario logueado. No verifica que la factura pertenezca
a la cuenta que hace el request.
Pasos para reproducir:
1. Loguearse como usuario A (tenant 101) y abrir la factura 5120.
2. Repetir el request cambiando el ID a 5121.
3. La API responde HTTP 200 con la factura del tenant 205.
Evidencia:
GET /api/invoices/5121 HTTP/1.1
Authorization: Bearer <token del usuario A>
HTTP/1.1 200 OK
{"id":5121,"tenant_id":205,"customer":"[REDACTADO]","total":"[REDACTADO]"}
Impacto:
Los IDs son secuenciales, así que un atacante con una cuenta gratis
puede bajar todas las facturas de la plataforma: nombres, direcciones
y montos. Es una filtración de datos personales según la mayoría de
las leyes de privacidad.
Remediación:
Limitar la query al tenant actual y responder 404 cuando la factura
no le pertenece:
const invoice = await Invoice.findOne({
where: { id: req.params.id, tenantId: req.user.tenantId }
});
if (!invoice) return res.status(404).end();
Agregar un test automatizado que pida la factura de otro tenant y
espere 404. Aplicar el mismo control a PUT y DELETE en esta ruta.
Referencias: OWASP WSTG Authorization Testing, CWE-639
Estado: AbiertoFijate en los detalles que hacen útil este hallazgo: un título que entiende un CEO, el archivo y la línea exactos, un request reproducible, evidencia redactada, impacto en términos de negocio y una corrección que el developer puede pegar. Y fijate también que el CVSS da Medium mientras el impacto de negocio es serio. Por eso el resumen ejecutivo lo puede poner igual entre las prioridades. Decilo de forma explícita en vez de inflar el score en silencio.
Escribir para ejecutivos vs. para developers
Para ejecutivos
- Arrancá por la conclusión. La primera frase dice el riesgo general y el problema más importante.
- Traducí el impacto. Hablá de datos de clientes, plata, caídas, contratos y compliance, no de parámetros y payloads.
- Dá decisiones, no listas. Tres acciones priorizadas con responsable y plazo sirven más que veinte hallazgos.
- Sé honesto con los límites. Decí qué no se probó. Un informe limpio sobre un alcance chico no es un certificado de salud.
- Evitá el miedo. Un lenguaje calmo y factual genera más confianza que los carteles en rojo.
Para developers
- Que cada hallazgo sea reproducible. Request exacto, rol de la cuenta, entorno y respuesta esperada contra la real.
- Apuntá al código cuando puedas. En un white box o en una auditoría de seguridad de código, archivo y línea ahorran horas.
- Proponé una corrección concreta en su stack y sugerí un test de regresión para que el bug no vuelva.
- Agrupá problemas relacionados. Si a doce endpoints les falta el mismo control de ownership, reportá una causa raíz con la lista completa de rutas afectadas.
- Redactá los datos sensibles en capturas y respuestas. El informe va a circular por mail.
Errores comunes en los informes de pentest
- Pegar el output de un scanner como hallazgos. Los resultados sin verificar van, como mucho, a un anexo. Si querés la capa automática, corré escáneres de vulnerabilidades open source antes del pentest, no dentro del informe.
- Severidad sin vector. Un "High" sin vector CVSS no se puede discutir ni verificar.
- Remediación genérica. "Validar el input" no es una corrección. Mostrá el cambio.
- Sin retest. Un informe sin remediación verificada es solo la mitad de la evidencia que piden los clientes.
- Límites de alcance ausentes. Si no decís qué no se probó, se lee como "se probó todo".
Testing continuo entre informes de pentest
Un informe de pentest manual es una foto. Tu código cambia todas las semanas, así que muchos equipos complementan el informe anual con testing continuo del propio código. Con Nurbak, por ejemplo, conectás GitHub y escaneás un repositorio: su propio modelo de IA self-hosted analiza el código (el análisis no envía tu código a OpenAI ni a Anthropic) y reporta vulnerabilidades explotables con archivo y línea, CVEs en dependencias, misconfigs de GitHub Actions, Docker, Terraform y Kubernetes y secretos en el historial de git, con un score de 0 a 100 y explicaciones en lenguaje simple. También puede abrir un Pull Request con el fix más un test de regresión de seguridad (el fix usa Claude, solo con tu consentimiento explícito). Mirá cómo funciona en la página de pentest con IA.
Eso no reemplaza a un tester humano para lógica de negocio y ataques encadenados. Si estás eligiendo uno, leé nuestra guía de empresas de pentesting y pedile a cada proveedor un informe de muestra antes de firmar.
En resumen
Un informe de pentest útil es corto arriba y preciso abajo: un resumen ejecutivo de una página, un alcance claro, una metodología con nombre, hallazgos con vector CVSS, CWE, evidencia y una corrección concreta, un rating general honesto y un retest. Copiá la plantilla de arriba, adaptala a tu contexto y escribí cada sección para su lector. Y si querés encontrar problemas antes del próximo pentest, arrancá con un pentest con IA de tu repositorio.