El informe es el único producto que queda cuando el pentest termina. Las horas de prueba se convierten en ese documento, y es él el que va a circular entre el equipo de desarrollo, la dirección y, muchas veces, un auditor. Aun así, buena parte de lo que el mercado entrega con el nombre de informe de pentest es lo mismo: la salida cruda de un escáner de vulnerabilidades, reformateada en un PDF con el logo del proveedor. Una lista de CVE, cada uno con su puntaje CVSS, ordenada por color. Ninguna prueba de que aquello fue explotado, ninguna lectura de lo que significa en ese entorno, ninguna instrucción que un desarrollador pueda seguir. Quien contrata por exigencia regulatoria suele descubrirlo tarde, cuando el documento tiene que aguantar una auditoría de verdad y no aguanta.
El informe es el producto, no un efecto secundario de la prueba
Cuando alguien contrata un pentest, lo que compra de verdad es el informe. La prueba en sí no deja nada palpable: nadie de la empresa observa al testeador trabajar, nadie guarda las solicitudes que envió. Todo lo que queda es el documento, y el valor del servicio entero queda atrapado en su calidad. Una prueba excelente descrita en un informe malo vale, en la práctica, lo que el informe logre comunicar, que es casi nada. Por eso evaluar a un proveedor de pentest por su informe no es un detalle: es mirar directo al único entregable que vas a recibir.
El problema es que el informe del escáner y el informe de pentest de verdad se parecen a primera vista. Los dos tienen portada, resumen ejecutivo, lista de hallazgos con severidad y una sección de recomendaciones. La diferencia está en el contenido de cada hallazgo, y aparece en tres lugares específicos: cómo se prueba el hallazgo, cómo se justifica la severidad y cómo se describe la corrección. Un informe que falla en los tres es un escaneo con ropa nueva. Vale la pena conocer cada uno, porque son exactamente los tres que puedes revisar por tu cuenta antes de firmar un contrato.
Elemento 1: evidencia reproducible, no captura genérica
Lo primero que separa un informe serio de uno adornado es la evidencia. Un hallazgo sin prueba es una opinión, y una opinión no sobrevive ni a un cuestionamiento del equipo de desarrollo ni a un auditor escéptico. Un escáner entrega, como mucho, la firma que coincidió y una captura de pantalla. Un informe de pentest de verdad entrega el camino: la solicitud exacta que se envió, la respuesta exacta que volvió, y los pasos para reproducirlo desde cero. Si el lector no puede repetir el hallazgo con lo que está escrito, no es evidencia, es una afirmación.
# Achado: acesso a pedido de outro cliente (BOLA)
# Endpoint: GET /api/v2/orders/{id}
# Passo 1 - autenticado como cliente A (id 8842), lendo o proprio pedido
GET /api/v2/orders/8842 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK {"order_id":8842,"customer_id":8842, ...}
# Passo 2 - MESMO token, pedido de outro cliente
GET /api/v2/orders/8843 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK {"order_id":8843,"customer_id":8843,"cpf":"***", ...}
# O token do cliente A leu o pedido do cliente B, com CPF.
# Reproduzido 4 vezes com ids sequenciais. Nenhuma versao
# desatualizada envolvida: e falha de logica de autorizacao.
Elemento 2: severidad ajustada al entorno, no CVSS puro
El segundo elemento es la severidad, y es donde el informe del escáner más engaña. La herramienta asigna el puntaje CVSS base del CVE y ahí se detiene. Pero el puntaje base se calcula para un mundo genérico, sin saber dónde está ese activo, qué dato guarda o si está expuesto a internet. El mismo hallazgo puede ser irrelevante en un servicio interno de prueba y crítico en una API pública que devuelve datos personales. Un informe que sirve ajusta la severidad a tu entorno y explica el ajuste; uno que solo copia el número de la herramienta te transfiere el trabajo de descubrir qué importa de verdad.
# Como o scanner reporta (nota base, isolada do ambiente):
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N -> 6.5 "Medio"
# O mesmo achado, dois ambientes reais:
# Ambiente 1 - endpoint interno de homologacao, sem dado real,
# so acessivel na VPN. Risco pratico: baixo.
# Ambiente 2 - MESMA falha, mas na API publica de producao que
# retorna CPF e historico de compra do cliente. Dado sensivel
# sob LGPD, exposto na internet. Risco pratico: alto.
# A nota base 6.5 nao muda entre os dois. O risco real, sim.
# O relatorio serio classifica pelo ambiente 2 e explica por que.Ajustar la severidad no es inflar un puntaje para asustar ni apretarlo para tranquilizar. Es hacer la lectura que la herramienta no puede hacer, porque no conoce tu topología, tu dato y tu exposición. Un informe honesto a veces baja un hallazgo que el escáner marcó como crítico, porque en tu entorno no alcanza nada, y explica por qué. Esa capacidad de subir y bajar la severidad con justificación es una de las señales más confiables de que hubo gente pensando, no solo una herramienta corriendo.
Elemento 3: remediación accionable, escrita para quien va a corregir
El tercer elemento es la remediación, y es el más desperdiciado. Mucho informe cierra el hallazgo con una recomendación genérica del tipo "implemente un control de acceso adecuado" o "aplique las mejores prácticas de seguridad". Eso no es remediación, es el título del problema repetido. Quien va a corregir es un desarrollador, y necesita saber dónde en el código, qué exactamente cambiar y cómo confirmar que la corrección funcionó. Una buena remediación se escribe para quien tiene el teclado, no solo para quien presenta el resumen al directorio.
# Remediacao generica (colada do scanner) - nao acionavel:
"Implemente controle de acesso adequado (OWASP A01)."
# Remediacao acionavel - escrita pra quem corrige:
# No handler de GET /api/v2/orders/{id}, depois de autenticar o
# token, validar que orders.customer_id == token.sub ANTES de
# retornar o objeto. O mesmo controller expoe PATCH e DELETE em
# /orders/{id}: os tres herdam a falha, corrigir os tres.
#
# Teste de regressao: token do cliente A pedindo pedido do B
# deve retornar 404 (nao 403 - o 403 ja confirma que o objeto
# existe). Adicionar esse caso na suite pra nao regredir.
Por qué esto reprueba en una auditoría de verdad
Cada vez más empresas contratan un pentest porque una norma pasó a exigirlo. En el sector financiero y en el de salud complementaria, entre otros, la prueba de seguridad periódica se volvió un ítem de conformidad, y el informe es la prueba de que ocurrió. El detalle que mucha gente descubre tarde es que tener el PDF en la mano no es lo mismo que tener una prueba que se sostiene. Un auditor competente no cuenta cuántos hallazgos lista el documento; pregunta cómo se comprobó cada uno y qué se hizo después. Ahí es donde el informe de escáner reformateado se desmorona.
Un documento que solo lista CVE con puntaje CVSS no muestra que hubo una prueba de intrusión, muestra que una herramienta corrió, lo que cualquiera hace por su cuenta. Sin evidencia reproducible, el auditor no puede confirmar que la falla era real y no un falso positivo del escáner. Sin severidad ajustada al entorno, no se puede justificar por qué un hallazgo se trató como prioridad y otro no. Sin remediación rastreable, no hay forma de ligar el hallazgo con la corrección que vino después. Los tres elementos que hacen útil a un informe en el día a día son exactamente los tres que una auditoría exige, y no es coincidencia: los dos quieren lo mismo, evidencia de que el riesgo se entendió y se atendió, no una lista de que apenas se listó.
Cómo evaluar el informe antes de firmar el contrato
La buena noticia es que puedes revisar todo esto antes de cerrar. Pide un informe de ejemplo (anonimizado) a cualquier proveedor que estés evaluando, un pedido normal que un proveedor serio atiende, y lee un hallazgo entero con estos puntos en la mano.
- Cada hallazgo serio trae la solicitud y la respuesta reales, o los pasos exactos para reproducir, no solo una captura y la firma que coincidió. Si no podrías repetir el hallazgo leyendo el informe, no es evidencia.
- Las severidades se justifican por tu entorno (dónde está el activo, qué dato guarda, si está expuesto), no solo el número CVSS copiado de la herramienta. Un informe que sube y baja el puntaje con explicación tuvo gente pensando.
- La remediación dice dónde y qué cambiar, y cómo probar la corrección, en un lenguaje que un desarrollador aplica. "Implemente un control adecuado" no es remediación, es el problema repetido.
- Aparecen hallazgos de lógica de negocio (acceso indebido a objeto, bypass de flujo, escalamiento por combinación de permisos), no solo versión desactualizada y configuración. Un informe 100% CVE de versión es un escaneo con portada.
- El informe distingue lo que se probó a mano de lo que fue apoyado por herramienta, e informa alcance y horas. Un escaneo puro no tiene esa distinción que hacer.
Contratar un pentest sin mirar el formato del informe es comprar a ciegas el único producto que vas a recibir. Antes de elegir proveedor, pide el modelo de entregable y presiona sobre los tres elementos: prueba reproducible, severidad en tu contexto y corrección que el desarrollador aplica. Si estás evaluando o comprobando a un proveedor y quieres un informe que aguante una auditoría en vez de solo cumplir el requisito, habla con nosotros en vorvex.com.br/orcamento: la conversación empieza por lo que vas a recibir al final, no por el color de la portada.