Pentest vs. Vulnerability Assessment: qué entrega cada uno (y por qué el scan no sustituye la prueba)

Categoría: Pentest | Vulnerability Assessment | Cumplimiento Nivel: Principiante a Intermedio Entorno: Laboratorio controlado — escenario totalmente anonimizado, sin datos reales de clientes

---

Introducción

Cada mes llega al equipo de seguridad una propuesta de "prueba de vulnerabilidades" con precio bajo e informe automático en 48 horas. Al mismo tiempo, el auditor de PCI-DSS pregunta si ya se hizo el pentest anual. Para quien no vive de la seguridad, la confusión es legítima: vulnerability assessment (VA) y penetration test (pentest) parecen lo mismo — ambos "buscan vulnerabilidades". No lo son.

La diferencia no es de precio, es de pregunta. El scan responde "¿qué CVEs conocidas existen en estos activos?". El pentest responde "¿qué puede hacer un atacante, en la práctica, con lo que existe — y qué le cuesta eso al negocio?". Una organización madura necesita los dos, en momentos diferentes, con propósitos diferentes. Este artículo explica la diferencia en un escenario anonimizado, muestra cuándo aplica cada uno y por qué ninguno de los dos, por sí solo, cumple lo que exigen LGPD, PCI-DSS e ISO 27001.

---

1. Qué es cada uno (definiciones sin jerga)

Vulnerability Assessment (VA / escaneo de vulnerabilidades)

Es un escaneo automatizado que compara versiones de software y configuraciones de un objetivo contra una base de conocimiento de vulnerabilidades conocidas (CVEs, plugins, bibliotecas). El entregable es una lista priorizada por severidad (CVSS), con la indicación de qué CVE afecta potencialmente a cada activo.

• Pregunta que responde: "¿Qué está desactualizado, mal configurado o con CVE conocida?"
• Cómo funciona: la herramienta corre en la red o en el host (Nessus, Qualys, OpenVAS, nuclei, escáneres de SAST en el código), compara con los feeds de CVE y genera el informe.
• Velocidad: días, cuando no horas — depende del tamaño del alcance.
• Falso positivo: alto. El scan correlaciona versión con CVE, pero no confirma si la condición de explotación existe de verdad (ej.: CVE que exige configuración específica, WAF bloqueando, funcionalidad desactivada).
• Depende del inventario: un scan solo ve lo que puede alcanzar y reconocer. Si el activo no está en el alcance o la versión es personalizada, queda ciego.

Penetration Test (pentest)

Es una prueba manual, adversarial y con objetivo, ejecutada por un profesional que piensa como atacante — con autorización escrita, alcance definido y reglas de compromiso. El pentester usa herramientas automatizadas como apoyo (enumeración, fuzzing), pero el núcleo del trabajo es humano: encadenar vulnerabilidades, probar lógica de negocio, intentar escalar privilegios, validar el impacto real.

• Pregunta que responde: "¿Qué puede hacer un atacante con esto — y cuál es el impacto real para el negocio?"
• Cómo funciona: reconocimiento → modelado de amenazas → explotación controlada → validación de cada hallazgo con PoC reproducible → informe con evidencia.
• Velocidad: semanas (típicamente 2-3 semanas para una aplicación web).
• Falso positivo: bajo — todo hallazgo se valida manualmente con prueba de explotación antes de entrar en el informe.
• Depende del alcance y del contexto: el valor está precisamente en lo que el escáner no ve — lógica de negocio, flujos de autenticación, encadenamiento de fallas.

---

2. Escenario de laboratorio: la "Alfa Retail"

Para hacer concreta la diferencia, usamos un escenario ficticio: la Alfa Retail, minorista con 400 tiendas, e-commerce propio y un sistema interno de CRM con datos de clientes (la LGPD en la cabeza de la dirección). El equipo de TI ejecuta un scan trimestral con una herramienta de VA desde hace dos años. Nadie cuestionó el proceso — hasta que el último informe del scan salió "100% limpio" la misma semana en que un pentest de laboratorio (autorizado, en entorno de staging) encontró lo que el scan no vio.

Lo que ocurrió en el escenario:

Hallazgo 1 — [CRÍTICO] IDOR en el CRM: el escáner no prueba lógica de negocio

El scan barrió el CRM, encontró la versión del framework sin CVE conocida y siguió adelante. El pentester, con una cuenta de usuario común, cambió el ID de un registro en la URL y accedió a la ficha completa de otro cliente — nombre, CPF, teléfono, historial de compras. El backend confiaba en el ID enviado por el cliente sin validar la autorización.

• Por qué el scan no lo vio: los accesos indebidos por objeto (IDOR) no son CVE — son una falla de lógica de autorización. Ningún feed de CVE describe "el sistema de Alfa valida IDs". Solo una prueba funcional, pensada de forma adversarial, encuentra esto.
• Qué reportaría el scan: nada. El informe salió "limpio".
• Mapeo OWASP Top 10 (2021): A01 Broken Access Control.

Hallazgo 2 — [ALTO] Encadenamiento: subida de avatar → RCE en el servidor

El scan identificó la versión del componente de subida como "sin CVE conocida". El pentester descubrió que la subida aceptaba extensiones arbitrarias, envió un archivo con contenido ejecutable y, combinado con la falta de segregación entre el directorio de subida y el servidor web, ejecutó comandos en el servidor.

• Por qué el scan no lo vio: cada pieza aislada parecía inofensiva (subida "validada" por extensión, directorio en el mismo host). El riesgo solo existe en el encadenamiento de las dos fallas — exactamente el tipo de razonamiento que un escáner no hace.
• Mapeo OWASP Top 10 (2021): A03 Injection + A05 Security Misconfiguration (encadenado).

Hallazgo 3 — [MEDIO] Fuga de datos en respuesta de API

Un endpoint legítimo devolvía, junto con el dato pedido, campos que la pantalla no usa: CPF completo del usuario conectado y de terceros, tokens internos de integración. El scan de infraestructura no hace llamadas funcionales autenticadas; solo la prueba manual con la aplicación en uso encontró el exceso de datos en la respuesta.

• Por qué el scan no lo vio: el VA evalúa el objetivo "por fuera" (banner, versión, puerto). El exceso de datos en un payload de API exige autenticación y conocimiento del flujo de negocio.
• Mapeo OWASP Top 10 (2021): A01 Broken Access Control (exposición excesiva de datos).

El resumen del escenario

El scan no es inútil — es incompleto para lo que Alfa necesitaba: saber si un atacante podría acceder a datos de clientes. Para esa pregunta, solo sirve la prueba manual.

---

3. Cuándo usar cada uno (y cuándo los dos)

Use vulnerability assessment cuando:

1. Frecuencia alta, costo bajo: cobertura continua entre pentests (ej.: scan mensual/trimestral, scan en el CI en cada deploy).
2. Inventario grande y dinámico: red con cientos de activos, donde el primer paso es saber qué existe y qué está desactualizado.
3. Triaje inicial: reducir el universo antes de la prueba manual — el scan señala candidatos a CVE que el pentester valida después.
4. Patch management: alimentar el proceso de corrección con priorización por CVSS y exposición.

Use pentest cuando:

1. La pregunta es "¿qué puede hacer un atacante?" — no "¿qué está desactualizado?".
2. Exigencia de cumplimiento: PCI-DSS Req. 11.4 (v4.0) exige pentests internos y externos anuales; LGPD Art. 46 exige medidas de seguridad técnicas — que los auditores y el DPO esperan ver evidenciadas por prueba, no por scan.
3. Aplicaciones con lógica de negocio: e-commerce, fintech, CRM, sistemas de pago — donde el riesgo está en los flujos, no en las versiones.
4. Antes de cambios significativos: lanzamiento de producto, nueva integración, migración de arquitectura.
5. Validación de controles: el pentest prueba si WAF, IDS y parches realmente impiden la explotación — el scan solo atestigua que existen.

La combinación correcta

Una postura de seguridad realista usa los dos en capas:

[VA continuo]  →  [triaje y parche]  →  [pentest periódico/anual]  →  [remediación]  →  [re-prueba]
      ↑                                                                              │
      └──────────────────────  bucle continuo (cadencia por riesgo)  ←──────────────┘

El VA mantiene la higiene básica entre los ciclos; el pentest valida si la higiene resiste a un atacante real. El error más común no es elegir uno — es tratar el scan como sustituto de la prueba y descubrir la diferencia en un incidente.

---

4. Por qué el scan no cumple compliance por sí solo

Los auditores y reguladores piden evidencia de prueba, no evidencia de escaneo:

El punto práctico: el informe de un pentest está firmado por un profesional, trae PoC reproducible para cada hallazgo y describe el impacto en lenguaje de negocio — lo que un auditor acepta como evidencia. El informe de un scan es un inventario de riesgo potencial, útil para el equipo técnico, pero no responde "¿la vulnerabilidad es explotable?".

---

5. Cómo evaluar una propuesta de pentest (checklist para quien contrata)

No toda propuesta llamada "pentest" es un pentest. Antes de firmar:

1. Alcance explícito — qué se probará (aplicaciones, APIs, red, mobile), con qué accesos (blackbox/graybox/whitebox) y en qué entorno (staging preferible).
2. Metodología declarada — OWASP WSTG/PTES como base, pruebas manuales de lógica de negocio previstas (no solo "ejecutar herramienta X").
3. Evidencia por hallazgo — el informe debe traer PoC reproducible (payload, paso a paso, captura) para cada vulnerabilidad.
4. Profesional responsable — informe firmado, con nombre y seniority; existe un humano detrás del análisis.
5. Validación de impacto — severidad clasificada por contexto de negocio (CVSS es el punto de partida, no la respuesta final).
6. Re-prueba incluida — verificación de remediación tras las correcciones (común: 1 ciclo de re-prueba en el alcance).
7. Plazo compatible — un pentest de aplicación web lleva semanas, no 48 horas. Entrega relámpago es señal de scan disfrazado.

---

6. Conclusión (y qué hacer el lunes)

• Si no tiene scan: empiece por él — es la capa de higiene continua y el costo es bajo.
• Si tiene scan y ningún pentest: la pregunta "¿qué puede hacer un atacante?" sigue sin respuesta. Programe el primer pentest en los activos que mueven datos sensibles o dinero.
• Si tiene los dos: verifique que el pentest cubra lógica de negocio y flujos autenticados — si el informe solo lista CVEs, contrató un scan más caro.

En el escenario de Alfa Retail, el scan "100% limpio" existía desde hacía dos años; el pentest de una semana encontró tres fallas explotables en datos de clientes. La diferencia no está en la herramienta — está en la pregunta que cada uno responde.

---

Este artículo describe un escenario de laboratorio totalmente ficticio, construido con fines educativos. No se utilizó ningún dato real de clientes. La explotación de vulnerabilidades en sistemas sin autorización explícita es ilegal.