Un reporte de pentesting no sirve si se queda en un PDF. El valor está en decidir qué se arregla primero y dejar evidencia de que el resto está contenido.
Empieza por explotabilidad, no por CVSS
El score ayuda a ordenar, pero no cuenta el contexto de tu producto. Prioriza primero lo que un atacante puede encadenar desde internet o desde una cuenta de usuario normal.
- Rutas autenticadas con impacto en datos de clientes.
- Hallazgos que permiten movimiento lateral (APIs, tokens, MCP tools).
- Misconfiguraciones de cloud que ya están expuestas.
- Deuda interna que no es explotable hoy.
Si no puedes demostrar explotabilidad en menos de una hora, no es P0. Es backlog con dueño.
Traduce el hallazgo a una decisión de producto
Cada ítem del reporte debería responder tres preguntas:
- Qué se rompe si alguien lo explota (datos, dinero, reputación, contrato).
- Quién lo arregla (backend, cloud, producto, proveedor).
- Cuándo queda cerrado y con qué evidencia.
Eso es lo que entregamos en el reporte ejecutivo de pentesting: no solo la prueba, sino el plan para actuar.
Un tablero mínimo que sí se usa
| Severidad | Criterio | SLA interno |
|---|---|---|
| Crítico | Explotable desde internet o afecta datos personales | 72 horas |
| Alto | Requiere usuario autenticado, impacto claro | 14 días |
| Medio | Defensa en profundidad / hardening | próximo ciclo |
| Bajo | Higiene y ruido residual | backlog |
El tablero vive junto al código, no en una planilla paralela. Si el hallazgo no tiene ticket, no existe.
Qué pedirle a un equipo de ethical hacking
Un buen ejercicio no termina en la lista de CVEs. Pide:
- Reproducción concreta (pasos, no capturas sueltas).
- Impacto de negocio en lenguaje de contrato y cliente.
- Mitigación temporal si el fix estructural tarda.
Cuando eso está claro, el pentesting deja de ser un evento anual y se vuelve una capacidad del producto.