Me han encargado redactar un informe de pentest: ¿qué debe incluir y qué formato funciona?

No olvides que los ejecutivos nunca leen las partes técnicas. Escribe las dos primeras páginas de forma que las entienda el subdirector general; por ejemplo, en lugar de decir "se encontró una inyección SQL", poner "existe el riesgo de filtración de datos de clientes en la base de datos de pedidos" transmite mejor la gravedad del asunto.

Al fijar los niveles de riesgo no te guíes por corazonadas, toma como referencia la lógica de puntuación CVSS. Si la falla se puede activar de forma remota o si requiere privilegios cambia directamente la nota. Tampoco olvides censurar datos sensibles y tokens de sesión en las capturas de pantalla.

Al armar el borrador de tu informe mantén este orden: 1) Resumen ejecutivo y puntuación general de riesgo, 2) Límites del alcance y fechas de la prueba, 3) Lista de vulnerabilidades y evidencias detalladas, 4) Plan de mitigación priorizado, 5) Explicación del proceso de re-test.

¿Había alguna especificación sobre el formato del informe en el contrato que firmaron con el cliente? Algunas empresas corporativas suelen pedir plantillas compatibles con ciertos estándares de auditoría pública o financiera, ¿lo confirmaron desde el principio para no andar renegando con revisiones después?

en mi primer informe traduje y entregué el reporte de 100 páginas que tiró la herramienta de escaneo automático y el cliente me puso una cagada bárbara. pongan solo vulnerabilidades verificadas que realmente funcionen en producción no metan paja innecesaria.

Que el propio equipo interno audite y reporte el software que ellos mismos desarrollaron puede generar desconfianza en el cliente. Dejen la metodología súper transparente en el informe para que la gente de sistemas del cliente no sospeche que "ocultaron sus propios errores".

Nosotros entregamos un promedio de diez informes similares al año. El porcentaje de implementación por parte de los equipos técnicos en informes de más de 40 páginas es muy bajo. Los informes de entre 15 y 20 páginas, claros y al grano, siempre dan mejores resultados.

si le pones al lado de cada hallazgo el esfuerzo estimado para solucionarlo los devs del cliente le van a dar bola mas rapido al informe buena suerte

Sí, la situación con redactar informe de pentest es exactamente así. Si la verificación en dos pasos está activa, una contraseña robada no sirve de nada por sí sola.

También me gustaría saber si alguien lo hace de otra manera.

buen trabajo.

Me quedé tranquilo al leer esta respuesta, así que no solo me pasa a mí. Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. Comprobado por experiencia.

Totalmente. Si tuviera que añadir algo más: Empezad con una pequeña prueba, no lo integréis todo de golpe.

Lo dejo como nota por si sirve.

si vas por ahí, resuelve esto desde el principio. en fin si la verificación en dos pasos está activa una contraseña robada no sirve de nada por sí sola.

lo dejo como nota, por si sirve.

Dejo una advertencia. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Yo seguiría por ese camino.

Le agradecería que compartiera el resultado. El tiempo que tardas en detectar un problema determina directamente su coste.

Espero que le sea útil.

Tema muy oportuno.

Gracias, me ha servido de mucha ayuda. Todo lo que no está por escrito ambas partes lo recordarán de forma distinta en el futuro.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Le agradecería que compartiera el resultado.