Cómo leer un informe de test de intrusión (VAPT): una guía en lenguaje sencillo para equipos

El resumen ejecutivo va al principio por una razón. Está escrito para personas que nunca leerán el detalle técnico, como tu CEO, tu junta directiva o el equipo de compras de un posible cliente. Debe contar la historia del trabajo realizado en lenguaje sencillo: qué se probó, qué tan saludable se veía la postura de seguridad en conjunto y cuáles fueron los problemas más graves.

Un buen resumen ejecutivo evita la jerga profunda y, en su lugar, responde a las preguntas que la dirección realmente hace. ¿Encontraron los evaluadores algo que pudiera provocar una brecha? ¿Están en riesgo los datos de los clientes? ¿Hay algo que deba corregirse antes del próximo lanzamiento? Suele incluir un recuento simple de hallazgos por severidad, para que puedas ver de un vistazo si estás ante un problema crítico o veinte de baja severidad.

Trata esta sección como el resumen que puedes compartir de forma más amplia dentro del negocio. Los hallazgos detallados que aparecen más adelante en el informe son para tus ingenieros; el resumen ejecutivo es la versión que ayuda a las partes interesadas no técnicas a entender por qué importa el trabajo y dónde concentrar la atención.

Antes de que cualquier hallazgo signifique algo, necesitas saber qué se probó en realidad. La sección de alcance enumera los activos concretos que entraron en juego: aplicaciones web específicas, APIs, rangos de IP, apps móviles o entornos en la nube. Todo lo que no figure aquí no se probó, lo cual importa enormemente cuando más adelante le dices a un cliente que tu producto ha sido evaluado.

Las reglas de compromiso describen cómo se llevó a cabo la prueba. Esto abarca la ventana de pruebas, si se realizaron contra producción o contra un entorno de preproducción, si los evaluadores tenían credenciales y documentación (una prueba de caja gris o de caja blanca) o partieron de cero (una prueba de caja negra), y cualquier sistema que estuviera explícitamente fuera de límites.

Lee esta sección con atención, porque define los límites de lo que el informe puede afirmar con honestidad. Un informe limpio frente a un alcance reducido no es lo mismo que un parte de salud limpio para toda tu plataforma. Si se excluyó un sistema importante porque no estaba listo a tiempo, esa carencia debe estar en tu radar, no oculta en una nota al pie.

La sección de metodología explica el enfoque y los estándares que siguieron los evaluadores. La mayoría de las pruebas serias se alinean con marcos reconocidos, como la OWASP Testing Guide para aplicaciones web, el OWASP API Security Top 10 para APIs, o el Penetration Testing Execution Standard para trabajos más amplios. Nombrar estos marcos te indica que el trabajo siguió un proceso establecido y repetible, en lugar de alguien hurgando al azar.

Esta parte suele describir las fases de la prueba: reconocimiento y mapeo de la superficie de ataque, identificación de vulnerabilidades, intento de explotarlas de forma segura y, después, documentación de lo encontrado. También puede enumerar las herramientas utilizadas, desde escáneres automáticos hasta herramientas de proxy manuales, junto con las técnicas manuales que los evaluadores aplicaron a mano.

No necesitas entender cada técnica nombrada aquí. Lo que quieres confirmar es que el trabajo combinó herramientas automáticas con pruebas manuales genuinas, porque esa combinación es lo que separa una evaluación rigurosa de un escaneo rápido.

Los hallazgos son el corazón del informe, y cada uno suele redactarse con una plantilla coherente para que tus ingenieros sepan exactamente dónde mirar. Entender los campos estándar hace que toda la sección sea mucho menos abrumadora.

La severidad es una calificación en lenguaje sencillo, normalmente desde crítica, pasando por alta, media, baja e informativa. Te indica con qué urgencia requiere atención algo.

La puntuación CVSS es un número estandarizado de 0.0 a 10.0 del Common Vulnerability Scoring System. Desglosa las características de una vulnerabilidad, como lo fácil que es explotarla y cuánto daño podría causar, en una puntuación coherente para poder comparar los problemas entre distintos informes.

La evidencia es la prueba. Aquí es donde ves capturas de pantalla, capturas de peticiones y respuestas, o datos extraídos que muestran que el problema es real y no teórico.

El impacto explica lo que un atacante podría lograr realmente, en términos de negocio. ¿Podría leer los datos de otros clientes, apoderarse de una cuenta o ejecutar comandos en tu servidor? Esta es la parte que conecta un fallo técnico con una consecuencia real.

Los pasos de reproducción son un recorrido numerado que permite a tus desarrolladores provocar el problema por sí mismos. Poder reproducir un error suele ser la vía más rápida para entenderlo y corregirlo.

La remediación es la corrección recomendada, idealmente lo bastante específica como para actuar, como un cambio de configuración, un patrón de código a adoptar o una librería a actualizar, en lugar de una instrucción vaga de ser más seguro.

Más allá de las correcciones individuales, un buen informe te ayuda a priorizar. Un plan de remediación agrupa los hallazgos en un orden de trabajo sensato, normalmente guiado por la severidad y por lo fácil que es desplegar cada corrección. El objetivo es evitar que trates una nota informativa cosmética con la misma urgencia que un fallo crítico que expone los datos de los clientes.

Una vez que tu equipo ha corregido los problemas, la reprueba cierra el ciclo. Los evaluadores vuelven a examinar cada hallazgo que se suponía resuelto y registran su nuevo estado: corregido, parcialmente corregido o todavía abierto. Una reprueba es lo que convierte una lista de problemas en evidencia de que realmente te ocupaste de ellos.

Tras una reprueba exitosa, la firma de pruebas puede emitir una carta de atestación. Es un documento breve y compartible que afirma que se realizó una evaluación, sobre qué alcance, y que los problemas identificados se remediaron. Es importante tener claro qué es esto: una atestación de un proveedor de test de intrusión es una declaración sobre el trabajo de pruebas realizado. No es una certificación ni una opinión de auditoría. Los certificados formales y las atestaciones de auditoría provienen únicamente de organismos acreditados independientes o de firmas de CPA autorizadas, lo cual es un proceso aparte del propio pentest.

Una vez que tienes el informe, dos audiencias ajenas a tu equipo de ingeniería suelen querer ver partes de él. La primera son los clientes, sobre todo los más grandes, que piden pruebas del test durante su revisión de seguridad de proveedores antes de firmar un contrato. En la mayoría de los casos compartirás el resumen ejecutivo y la carta de atestación en lugar de los hallazgos técnicos completos, ya que el informe detallado es un mapa de tus debilidades y debe manejarse con cuidado.

La segunda audiencia son los auditores que trabajan hacia marcos como SOC 2 o ISO 27001. Para ellos, el pentest es evidencia de que ejecutas un programa creíble de gestión de vulnerabilidades. Quieren ver que las pruebas se hicieron con una cadencia sensata, que los hallazgos se dieron seguimiento y que se remediaron y reprobaron en lugar de dejarse abiertos. El estado de la reprueba y el plan de remediación suelen interesar más a un auditor que las vulnerabilidades en sí, porque demuestran un proceso que funciona.

En ambos casos, recuerda quién certifica qué. Una firma de pruebas informa de lo que encontró y confirma lo que se corrigió. El certificado o el informe de auditoría los otorga por separado el organismo de certificación acreditado o la firma de CPA que gestiona ese programa.

Los escáneres automáticos son útiles y rápidos, pero su salida en bruto es muy distinta a un informe de test de intrusión como es debido. Un escáner produce una larga lista de posibles problemas basada en coincidencia de patrones, y no puede decir cuáles son realmente explotables en tu entorno específico. Esa lista suele estar llena de falsos positivos y duplicados, y rara vez explica el impacto para el negocio.

Un informe manual refleja a una persona que validó cada problema, descartó el ruido y encadenó problemas que un escáner reportaría de forma aislada. Un evaluador podría combinar una fuga de información de baja severidad con una política de contraseñas débil para demostrar la toma completa de una cuenta, algo que ningún hallazgo aislado de un escáner revelaría. Ese razonamiento sobre cómo se combinan los fallos es precisamente lo que las herramientas automáticas pasan por alto.

La diferencia práctica aparece en la redacción. Un volcado de escáner dice que existe una vulnerabilidad. Un informe manual te muestra la evidencia, explica lo que un atacante podría hacer con ella en tu contexto, da a tus desarrolladores pasos de reproducción y recomienda una corrección dirigida. Cuando un cliente o un auditor pide un test de intrusión, esto es lo que esperan: este informe validado y escrito por una persona, no un escaneo exportado.