Llega el PDF con la palabra "confidencial" en el pie, cuarenta páginas y una lista de hallazgos con colores. La tentación es ir directo a contar cuántos hay en rojo. Es una mala forma de empezar: un informe de pentest se lee para decidir qué hacer el lunes, y eso exige entender cómo está armado y qué dice cada parte, y qué no.
Dos lectores, dos secciones
Un buen informe tiene un resumen ejecutivo y un detalle técnico, y cada uno apunta a un lector distinto. El resumen es para quien decide presupuesto y prioridades: qué se probó, con qué alcance, qué riesgo general se observó y qué conviene hacer primero. Tiene que entenderse sin saber qué es una inyección SQL.
El detalle técnico es para quien va a corregir. Si el informe no te permite a vos o a tu equipo reproducir cada hallazgo, falta algo. Y antes de leer cualquiera de los dos, mirá el alcance: qué sistemas entraron, qué quedó afuera, en qué fechas y con qué condiciones (con o sin credenciales, sobre producción o sobre un entorno de pruebas). Una frase como "no se encontraron problemas críticos" significa algo muy distinto según lo que se haya mirado.
Cómo está compuesto un hallazgo
Cada hallazgo debería traer, como mínimo:
- Una descripción de qué ocurre y dónde.
- La evidencia: capturas, peticiones y respuestas, fragmentos de salida.
- Los pasos para reproducirlo.
- El impacto en términos de negocio y no únicamente técnico.
- Una recomendación concreta de corrección.
La evidencia es lo que separa un hallazgo confirmado de una sospecha. Si dice "posible vulnerabilidad" sin pruebas, pedí que la aclaren.
Entender la gravedad
La gravedad suele salir de combinar dos cosas: cuánto daño causaría la explotación y qué tan fácil o probable es lograrla. Una falla que expone datos de todos los clientes pero exige acceso previo a la red interna puede pesar menos que una más modesta que cualquiera dispara desde internet sin cuenta. Muchos informes usan una escala estándar de puntaje, y ese número sirve como guía, pero no conoce tu negocio.
Por eso, la gravedad que figura en el papel es un punto de partida que tenés que ajustar. Preguntate qué datos hay en ese sistema, qué pasaría si se filtraran, si hay otra defensa que reduce el riesgo y si alguien ya intentó algo parecido. Dejá asentado el razonamiento, porque dentro de seis meses nadie se va a acordar por qué algo pasó de "alto" a "medio".
Falsos positivos y hallazgos dudosos
Los informes, sobre todo los que se apoyan mucho en escáneres automáticos, pueden incluir hallazgos que no aplican: una versión que parece vulnerable pero tiene el parche aplicado por el proveedor, una cabecera ausente en una ruta que no sirve contenido. No los descartes por intuición. Pedí a quien hizo la prueba que confirme o retire el hallazgo, o reproducilo vos. Y aceptá que lo contrario también pasa: un resultado que parece menor puede ser la pieza que, combinada con otra, abre el camino.
Agrupar por causa raíz
Veinte hallazgos pueden venir de tres causas. Si diez endpoints no verifican quién es dueño del recurso, el problema es una convención de autorización ausente, no diez errores sueltos. Si hay cuatro formularios con salida sin escapar, quizás el problema es una plantilla compartida. Reordenar la lista por causa te da menos tareas, mejor arreglo y menos reincidencia, porque corregís el origen y no cada síntoma.
Responsables y plazos
Una corrección sin nombre y sin fecha no avanza. Para cada grupo de hallazgos definí quién lo toma, para cuándo y cómo se va a comprobar que quedó resuelto. Un criterio razonable de orden combina gravedad ajustada, exposición (lo que se ve desde internet va antes) y esfuerzo: si algo grave se arregla en una hora, hacelo ya, y lo que lleve semanas arrancá a planificarlo el mismo día.
Anotá también lo que decidas no corregir, con quién lo aprobó y bajo qué supuestos. Aceptar un riesgo es legítimo; olvidarlo, no.
Una última lectura
Terminada la primera pasada, hacé una reunión corta con quien redactó el informe. Preguntas útiles: cuál es el hallazgo que más les preocupó aunque no sea el de mayor puntaje, qué cosas notaron que no son vulnerabilidades pero les llamaron la atención, y qué esperan que se vuelva a probar. Esas respuestas suelen valer más que un apéndice entero.