Test de intrusión vs análisis de vulnerabilidades: cuál es la diferencia (y cuándo necesitas cada uno)

El año pasado un cliente potencial nos envió un informe de escaneo del que estaba orgulloso. Cero hallazgos altos, cero críticos, un muro de verde. A las dos semanas del test real, uno de los nuestros cambió un solo número en una ruta de API y sacó las facturas de otro inquilino. El escáner nunca tuvo la menor posibilidad ante ese hallazgo, porque la petición era HTTP perfectamente válido. Esa brecha – entre “aquí tienes una lista de problemas conocidos” y “así es como alguien entra de verdad” – es toda la historia del test de intrusión frente al análisis de vulnerabilidades.

Hacemos ambos para nuestros clientes. Resuelven problemas distintos, y tratarlos como la misma partida es como una empresa acaba con un informe de escaneo limpio y un incidente en el mismo trimestre. Así que seamos precisos: qué hace cada uno, dónde falla cada uno y cuándo tu presupuesto o tu auditor exige uno, el otro o ambos.

Puntos clave

• El análisis de vulnerabilidades es automatizado, amplio y rápido. Coteja tus sistemas contra una base de datos de fallos conocidos y versiones obsoletas. El test de intrusión es manual, profundo y orientado a objetivos: una persona intenta explotar de verdad y encadenar las debilidades como lo haría un atacante.
• Los escáneres son excelentes en cobertura y pésimos en contexto. Se les escapan los fallos de lógica de negocio, el control de acceso roto y los ataques encadenados, y generan falsos positivos que alguien todavía tiene que triar a mano.
• Un pentest confirma un impacto real (“llegamos al panel de administración y leímos cada registro de usuario”). Un escaneo informa de una exposición teórica (“este componente tiene una CVE conocida”).
• La mayoría de los marcos de cumplimiento (PCI DSS, SOC 2, ISO 27001, HIPAA) esperan un escaneo regular como base y, por encima, un test de intrusión periódico. No son intercambiables.
• La respuesta correcta suele ser ambos: escaneo continuo para atrapar lo evidente y gestionar los hallazgos con el tiempo, más pruebas manuales programadas para atrapar lo que las herramientas no pueden.

¿Qué es el análisis de vulnerabilidades?

El análisis de vulnerabilidades es un proceso automatizado que inspecciona tus sistemas y los compara con una base de datos de vulnerabilidades conocidas, configuraciones incorrectas y software obsoleto. Herramientas como Nessus, Qualys, OpenVAS o nuclei enumeran hosts, identifican servicios y marcan todo lo que coincide con una firma: una compilación de Apache sin parchear, una credencial por defecto, una interfaz de administración expuesta, una cabecera de seguridad ausente.

Es rápido y repetible. Puedes apuntar un escáner a unos cuantos miles de hosts durante la noche y tener por la mañana una lista ordenada, normalmente con puntuaciones CVSS adjuntas. Esa velocidad es justo por lo que merece un sitio en tu rutina. El escaneo es el latido de un programa de gestión de vulnerabilidades – lánzalo cada semana, lánzalo después de cada despliegue, lánzalo sobre todo el parque. Responde a la pregunta “¿qué problemas conocidos tenemos ahora mismo?” mejor de lo que podría cualquier persona a esa escala.

Lo que no hace es pensar. Un escáner no tiene ni idea de que tu aplicación tiene una función de cuentas, ni de que el usuario 1001 nunca debe ver los datos del usuario 1002. Conoce patrones. No conoce la intención.

¿Qué es el test de intrusión?

El test de intrusión es una evaluación manual y orientada a objetivos en la que un tester competente se comporta como un atacante real: mapear el entorno, encontrar debilidades, explotarlas y coser varios problemas pequeños hasta convertirlos en un impacto serio. El entregable no es una lista de firmas. Es un relato de hasta dónde podría llegar alguien, qué podría alcanzar y cuánto te costaría el día que lo hiciera.

En nuestros proyectos, los hallazgos que importan casi nunca salen de una herramienta. Salen de alguien que se da cuenta de que un flujo de “olvidé mi contraseña” devuelve el token de restablecimiento en el cuerpo de la respuesta, o de que una API confía sin más en un campo role proporcionado por el cliente, o de que una subida de archivos acepta un SVG que dispara un XSS almacenado en el panel de administración. El control de acceso roto – el riesgo web número uno de OWASP, A01 – es el ejemplo más claro. Un escáner no puede razonar sobre quién tiene permiso para hacer qué. Una persona inicia sesión como usuario de bajos privilegios y empieza a hurgar en cosas que no debería poder tocar.

Este es el tipo de comprobación que queda por completo fuera del alcance de un escáner. Dos cuentas, una petición, se intercambia el identificador:

GET /api/v2/invoices/4471 HTTP/1.1
Host: api.example.com
Authorization: Bearer <low-priv-user-token>

# Response: 200 OK - invoice belongs to a DIFFERENT tenant
# Insecure Direct Object Reference (IDOR), CWE-639

Nada de eso dispara una firma. La URL está bien formada, el token es válido, el servidor responde 200. Solo un tester que sabe que la factura 4471 debería pertenecer a otra persona reconoce aquí una vulnerabilidad crítica. Vemos esto constantemente en las pruebas de API, y el instrumental automatizado pasa de largo tan tranquilo.

¿Dónde fallan de verdad los escáneres?

Los escáneres fallan en tres puntos predecibles, y entenderlos es como decides dónde invertir.

Lógica de negocio. Una herramienta no puede entender tu flujo de trabajo. No sabe que aplicar un código de descuento, cancelar el pedido y luego volver a añadir artículos no debería dejar el descuento aplicado. No sabe que una cantidad negativa en un carrito nunca debería abonar dinero a la cuenta. Estos son los fallos que cuestan dinero de verdad, y son invisibles para la comparación de firmas.

Explotación encadenada. Los escáneres puntúan los hallazgos de forma aislada. Una página de error demasiado verbosa (baja), un token de sesión predecible (media), una redirección abierta (baja) – cada uno parece ignorable por sí solo. Encadénalos y tienes una toma de control de cuenta. Los atacantes piensan en cadenas. Las herramientas piensan en filas de una hoja de cálculo.

Control de acceso y lógica de autenticación. IDOR, escalada de privilegios, aislamiento entre inquilinos roto, debilidades de JWT. Esta es la categoría de mayor impacto que reportamos, y es casi por completo trabajo manual.

Luego está el ruido. Los escáneres producen falsos positivos todo el día: un banner de versión “vulnerable” que ya había sido parcheado a posteriori, una cabecera marcada en un endpoint que debe ser público, una CVE que no aplica porque nunca se llega al camino de código vulnerable. Alguien tiene que sentarse y triar cada uno de ellos. La otra cara es más silenciosa y peor. Un falso negativo – un informe limpio de una herramienta que, literalmente, no puede ver los fallos de lógica – alimenta justo el tipo de confianza que acaba con una brecha en el equipo. Convencerte de que tienes un panel en verde no hace segura la aplicación.

Test de intrusión vs análisis de vulnerabilidades: una comparación directa

Versión corta: el escaneo te da amplitud, el pentest te da profundidad y prueba. El escaneo es un detector de humo en cada planta. Un pentest es un equipo que intenta quemar el edificio en condiciones controladas y luego te dice exactamente por dónde se propagaría el fuego.

• Método: el escaneo es automatizado; el pentest lo dirige una persona con apoyo de herramientas (Burp Suite, ffuf, sqlmap, BloodHound, Impacket, más scripts a medida).
• Profundidad: el escaneo coteja firmas conocidas; el pentest explota y encadena, incluidos fallos desconocidos y de lógica.
• Resultado: el escaneo lista problemas potenciales con CVSS; el pentest prueba un impacto real con pasos de reproducción y evidencias.
• Falsos positivos: frecuentes en el escaneo, mínimos en un buen pentest porque una persona verifica cada hallazgo.
• Frecuencia y coste: el escaneo es barato y continuo; el pentest es periódico, más caro y acotado en el tiempo.

¿Cuándo necesitas cada uno?

El análisis de vulnerabilidades lo necesitas de forma continua. Es higiene básica. Si publicas código o gestionas infraestructura y no escaneas según un calendario, empieza hoy mismo por ahí. Atrapa la fruta al alcance de la mano – parches ausentes, servicios expuestos, configuraciones débiles – de forma barata, y mantiene una imagen viva de tu exposición entre las evaluaciones más profundas.

El test de intrusión lo necesitas en momentos concretos: antes de un lanzamiento importante, tras un cambio de arquitectura significativo, cada año para un producto maduro y siempre que manejes datos sensibles o dinero. Si la entrada de un atacante real fuese a convertirse en titular o en demanda, quieres que una persona lo haya intentado primero.

El ángulo del cumplimiento zanja la mayoría de las discusiones. PCI DSS exige explícitamente ambos: escaneos de vulnerabilidades regulares (escaneos externos trimestrales por un proveedor de escaneo aprobado para los sistemas dentro del alcance) y un test de intrusión al menos una vez al año y tras cualquier cambio significativo. Los programas alineados con SOC 2, ISO 27001 y HIPAA esperan un proceso de gestión de vulnerabilidades que funcione más pruebas independientes periódicas. Los auditores conocen la diferencia aunque los proveedores la difuminen. Entrégale a un auditor un informe de escaneo donde se exige un pentest y obtendrás un hallazgo, no un aprobado.

¿Cómo los combinas en un solo programa?

Trata el escaneo y el pentest como dos engranajes de la misma máquina, no como una elección entre uno u otro. El escaneo corre de forma continua y alimenta un flujo de gestión de vulnerabilidades: los hallazgos se trían, se deduplican, se priorizan por exposición real, se asignan a un responsable y se siguen hasta el cierre contra los SLA. Las pruebas manuales siguen una cadencia, validan lo que las herramientas no alcanzan y luego reinyectan sus propios hallazgos en el mismo sistema de seguimiento para que nada se caiga en silencio del tablero.

El error que vemos con más frecuencia es una empresa que compra un escáner, genera miles de hallazgos y se ahoga en ellos. Volumen sin priorización no es seguridad. Es un backlog con una etiqueta de seguridad encima. El valor vive en el proceso alrededor de la herramienta – saber cuáles de esas 4.000 filas son realmente alcanzables, realmente explotables y realmente merecedoras de una tarde de un ingeniero.

Cómo ayuda CyberXplore

Este es exactamente el ciclo alrededor del cual está construido nuestro servicio de evaluación y gestión de vulnerabilidades. No solo lanzar escaneos, sino operar el ciclo completo: escaneo continuo, validación humana para descartar los falsos positivos, priorización basada en el riesgo y seguimiento de cada hallazgo hasta el cierre. Cuando un objetivo necesita una simulación de ataque manual más profunda, nuestros testers toman el relevo donde las herramientas se detienen e integran esos resultados de vuelta en el mismo programa gestionado, de modo que acabas con una imagen clara en lugar de una docena de PDF inconexos.

¿No estás seguro de si necesitas un escaneo, un pentest completo o un programa gestionado continuo? Cuéntanos tu stack, tus motivos de cumplimiento y tus plazos. Solicita un presupuesto y dimensionaremos algo honesto – nadie va a venderte un red team cuando lo que tu riesgo pide de verdad es un escaneo trimestral más una prueba anual de la aplicación web.

FAQ

¿Es lo mismo un escaneo de vulnerabilidades que un test de intrusión?

No. Un escaneo de vulnerabilidades es una comprobación automatizada contra una base de datos de problemas conocidos; señala problemas potenciales pero no los explota ni confirma un impacto real. Un test de intrusión es un esfuerzo manual, dirigido por una persona, para entrar de verdad, encadenar debilidades y demostrar hasta dónde podría llegar un atacante. Algunos proveedores venden un escaneo automatizado como un “pentest” – es una señal de alarma que conviene cuestionar antes de firmar nada.

¿Puede un escáner de vulnerabilidades encontrar todo lo que encuentra un pentester?

No, y nunca se diseñó para eso. Los escáneres son excelentes en amplitud y en cobertura de CVE conocidas, pero ciegos ante los fallos de lógica de negocio, el control de acceso roto y los ataques encadenados que exigen razonar sobre la intención. En esas categorías es donde suelen vivir los hallazgos de mayor gravedad, y necesitan a una persona.

¿Con qué frecuencia deberíamos escanear frente a hacer pentest?

Escanea de forma continua, o al menos cada semana, y después de cada despliegue significativo – es barato y atrapa rápido lo evidente. El test de intrusión suele ser anual para un producto maduro, más los que se hacen tras cambios importantes o antes de un gran lanzamiento. Los entornos regulados como los sujetos a PCI DSS imponen para ambos cadencias más estrictas y explícitas.

¿De verdad importan tanto los falsos positivos?

Sí. La salida de escáner sin validar quema tiempo de ingeniería persiguiendo problemas que no son explotables, y erosiona la confianza en todo el programa. Un buen proceso gestionado valida primero los hallazgos, de modo que tu equipo solo invierte esfuerzo en lo que es genuinamente alcanzable y merece la pena arreglar.

¿El cumplimiento me permite elegir uno en lugar del otro?

Normalmente no. Marcos como PCI DSS exigen escaneo regular y test de intrusión periódico como obligaciones separadas, y los auditores de SOC 2 e ISO 27001 esperan un proceso de gestión de vulnerabilidades junto a pruebas independientes. Sustituir uno por el otro tiende a producir un hallazgo de auditoría en lugar de un aprobado.

Tenemos un presupuesto ajustado – ¿por dónde empezamos?

Empieza por un análisis de vulnerabilidades continuo envuelto en un proceso de gestión de verdad, porque te da la mayor cobertura por euro y cierra las brechas fáciles que los atacantes golpean primero. Luego añade un test de intrusión manual enfocado en tu aplicación más sensible, expuesta a Internet o que maneje dinero. Ese orden te compra la mayor reducción de riesgo antes de escalar el gasto.