Qué revisar en un informe de pentesting

Empezar por el alcance

Antes de leer la lista de hallazgos, comprobá qué activos, versiones y roles se evaluaron. Un resultado tiene sentido en esas condiciones. Si el sistema tiene funciones administrativas y solo se probaron cuentas de operador, la conclusión debe conservar ese límite.

Buscá también restricciones: una integración no disponible, datos insuficientes o un entorno distinto de producción. Una ausencia de hallazgos sobre una función inaccesible no permite concluir que su control funciona.

Seguir el recorrido de una afirmación

Cada hallazgo debería relacionar una condición con un comportamiento y una consecuencia. En una muestra ficticia, un operador de la organización A accede a un documento de B. La condición es una sesión válida y una referencia conocida; el comportamiento es la entrega del documento; el impacto es la pérdida de separación entre organizaciones.

La evidencia tiene que respaldar esa conclusión. Si solo acredita lectura de un documento sintético, no demuestra modificación de todo el sistema. Una captura aislada también puede necesitar una explicación sobre identidad, entorno y operación.

Entender la prioridad

La severidad técnica describe condiciones e impacto del problema. La prioridad de corrección también depende de la exposición, del uso del producto y de los controles disponibles. El informe debe explicar su criterio y las suposiciones que influyen en él.

Si se usa CVSS, pedí la versión y el vector que sustentan la puntuación. Un número sin contexto no comunica qué privilegios, interacción o condiciones requiere el escenario. La documentación de FIRST sobre CVSS permite consultar el sistema de puntuación.

Evaluar la recomendación

Una recomendación útil identifica el control que debe cambiar. “Mejorar la validación” resulta difícil de convertir en una tarea. En el ejemplo documental, verificar pertenencia y permiso de la operación en el servidor describe una decisión concreta.

La solución también necesita preservar los usos legítimos. Una comprobación puede confirmar que A pierde el acceso al documento de B y que B conserva el acceso permitido. Las rutas alternativas incluidas, como la descarga, necesitan la misma interpretación.

Distinguir corrección y revalidación

Un estado “corregido” informado por desarrollo indica que existe un cambio. La revalidación añade evidencia sobre el comportamiento de una versión determinada. El registro debería indicar qué se comprobó, cuándo, con qué accesos y qué no pudo probarse.

La muestra navegable y descargable permite recorrer estos elementos con datos ficticios. Es un ejemplo de estructura; el formato y el seguimiento de una evaluación real se definen en la propuesta.

Referencias

Consultá la OWASP Web Security Testing Guide como referencia de evaluación y nuestra metodología de comunicación y seguimiento para preparar el cierre del trabajo.