La gestión de vulnerabilidades y el pentest responden preguntas distintas. La gestión de vulnerabilidades es un proceso continuo que descubre, prioriza y corrige fallas conocidas a escala. El pentest es una evaluación puntual que explota fallas — conocidas o no — para probar impacto real. Uno cubre amplitud; el otro, profundidad. Los programas maduros usan ambos.
Confundir los dos es una de las causas más comunes de presupuesto de seguridad mal invertido. Una empresa ejecuta un escáner, recibe un informe con miles de ítems y cree que hizo un "pentest". Otra contrata una prueba de penetración anual y asume que está cubierta todo el año. Ninguna se equivoca sobre la herramienta que usó — se equivoca sobre lo que esa herramienta prueba. Este artículo separa los conceptos y muestra cómo encajarlos en un único programa.
¿Qué es la gestión de vulnerabilidades?
La gestión de vulnerabilidades es el ciclo operativo de identificar, clasificar, priorizar, corregir y verificar fallas conocidas en todo el parque tecnológico. Es continua por definición: nuevos activos entran en producción, se publican nuevas CVE todos los días y las configuraciones cambian. Un proceso maduro recorre estas etapas de forma recurrente:
- Descubrimiento e inventario — mapear activos, servicios expuestos, versiones de software y dependencias. Sin un inventario confiable no hay gestión de vulnerabilidades, solo escaneos a ciegas.
- Escaneo — escáneres autenticados y no autenticados comparan lo que existe en el entorno con bases de vulnerabilidades conocidas (CVE) y reglas de configuración.
- Priorización — no todas las fallas importan igual. La priorización combina severidad técnica (CVSS), probabilidad de explotación (por ejemplo, indicadores como EPSS y la presencia en catálogos de explotación activa) y el contexto del activo: un ítem de severidad media en un servidor de pagos expuesto puede superar a uno alto en una estación aislada.
- Remediación — aplicar correcciones, ajustar configuraciones o mitigar el riesgo con controles compensatorios cuando el parche no es viable.
- Verificación — volver a escanear para confirmar que la corrección surtió efecto y no introdujo regresiones.
Lo que la gestión de vulnerabilidades entrega bien es cobertura y velocidad. Ve el entorno completo en ciclos cortos y avisa rápido cuando surge una nueva falla crítica. Lo que no hace es probar que una falla sea realmente explotable en su contexto, ni encadenar varias debilidades menores en un compromiso real. Los escáneres generan falsos positivos y, sobre todo, no entienden la lógica de negocio.
¿Qué es un pentest?
Un pentest, o prueba de penetración, es una evaluación conducida por especialistas que explotan activamente las fallas de un objetivo definido para demostrar impacto concreto. En lugar de listar lo que podría salir mal, el pentest muestra lo que sale mal: hasta dónde llega un atacante, qué datos alcanza y qué puede hacer con ese acceso.
La diferencia central es el método. Un escáner correlaciona versiones y firmas; un pentester razona como adversario. Encadena fallas — combina una configuración débil con una credencial reutilizada y una falla de autorización para llegar a un objetivo — y prueba la lógica de negocio, terreno en el que los escáneres son ciegos: abusar de un flujo de checkout, manipular un parámetro de autorización, eludir una regla de aprobación.
Los pentests se organizan por objetivo y por nivel de conocimiento entregado al equipo. Entre las modalidades más contratadas están el pentest de red, el pentest de API, el pentest cloud y el pentest mobile, además de ejercicios de Red Team con objetivos definidos que miden detección y respuesta. Cada proyecto termina con hallazgos priorizados, prueba de concepto reproducible y recomendaciones de corrección.
Lo que el pentest entrega bien es profundidad y evidencia. Valida la explotación real, revela cadenas de ataque que ningún escáner arma y traduce riesgo técnico en impacto de negocio. Lo que no hace es cubrir todo el entorno de forma continua: es una fotografía de un alcance específico en un momento específico.
¿Cuál es la diferencia entre gestión de vulnerabilidades y pentest?
La tabla siguiente resume los ejes que más confunden a las dos prácticas.
| Criterio | Gestión de vulnerabilidades | Pentest |
|---|---|---|
| Objetivo | Encontrar y corregir fallas conocidas a escala | Probar impacto explotando fallas en profundidad |
| Cobertura | Amplia — todo el entorno | Focalizada — alcance definido |
| Frecuencia | Continua (escaneos recurrentes) | Puntual (por proyecto o ventana) |
| Método | Automatizado, basado en firmas y CVE | Manual y creativo, conducido por especialistas |
| Encadena fallas | No | Sí |
| Prueba lógica de negocio | No | Sí |
| Falsos positivos | Comunes, exigen triaje | Raros — los hallazgos se validan |
| Prueba de concepto | No | Sí |
| Resultado | Lista priorizada de vulnerabilidades | Cadenas de ataque con impacto demostrado |
| Costo por ciclo | Menor, recurrente | Mayor, concentrado |
Ninguna columna es "mejor". Miden cosas distintas. La gestión de vulnerabilidades responde "¿dónde están mis fallas conocidas hoy?". El pentest responde "¿qué puede hacer realmente un atacante con lo que existe aquí?".
¿Con qué frecuencia ejecutar cada uno?
La gestión de vulnerabilidades es continua — esa es su naturaleza. En la práctica, suele significar escaneos autenticados en ciclos cortos (mensual es un piso razonable para muchos entornos), escaneos no autenticados del perímetro externo con frecuencia aún mayor, y verificación siempre que haya un cambio significativo: un nuevo sistema en producción, una alteración de arquitectura o la publicación de una CVE crítica que afecte a su stack.
El pentest es periódico y orientado a eventos. La buena práctica combina una cadencia de calendario con disparadores:
- Anualmente, como mínimo, para los sistemas críticos y el perímetro expuesto.
- Después de cambios relevantes — una nueva aplicación, un rediseño de arquitectura, una migración a la nube o la exposición de una nueva API.
- Antes de hitos de negocio — el lanzamiento de un producto, una auditoría, una due diligence de adquisición.
Los requisitos regulatorios y contractuales suelen definir la cadencia mínima. PCI DSS, por ejemplo, exige escaneos de vulnerabilidades internos y externos al menos trimestrales (los externos por un ASV) y pruebas de penetración al menos anuales, además de repeticiones tras cambios significativos — un caso claro en el que ambos procesos son obligatorios y complementarios. En el sector financiero brasileño, las resoluciones del BACEN/CMN sobre seguridad cibernética, incluida la 4.893, tratan la gestión de vulnerabilidades y las pruebas como parte de un programa continuo de resiliencia. Verifique siempre la norma aplicable a su sector antes de fijar una cadencia.
¿Uno sustituye al otro?
No. Tratar a uno como sustituto del otro deja brechas previsibles, y aquí es donde falla la mayoría de los programas:
- Solo gestión de vulnerabilidades — usted ve fallas conocidas, pero nunca sabe si son explotables en su contexto ni cómo se encadenan. Las fallas de lógica de negocio y de autorización pasan desapercibidas, porque ningún escáner las entiende. El informe tiene volumen, pero no impacto demostrado, y la priorización se vuelve un juego de adivinanzas.
- Solo pentest — usted tiene profundidad una o dos veces al año, pero el entorno cambia todos los días. Entre una prueba y otra surgen nuevas CVE, nuevos activos entran en producción y la superficie de ataque crece sin monitoreo. La fotografía envejece rápido.
Los dos procesos se refuerzan en un ciclo. La gestión de vulnerabilidades reduce el ruido: cuando el pentester llega, lo "básico" ya está corregido, y la prueba se concentra en lo que exige inteligencia humana — cadenas de ataque, lógica de negocio, fallas de diseño. El pentest, a su vez, calibra la gestión de vulnerabilidades: al probar qué fallas importan realmente en su entorno, muestra dónde la priorización automatizada se equivocaba y ayuda a afinar lo que merece atención urgente. En un pipeline de DevSecOps, el escaneo continuo entra en el CI/CD y el pentest valida los releases más sensibles.
Cómo lo ejecuta Berghem
Berghem trata la gestión de vulnerabilidades y el pentest como capas de un mismo programa, no como servicios que compiten. El punto de partida es siempre el alcance real: qué activos existen, cuáles son críticos, qué obligaciones regulatorias aplican y dónde la explotación causaría más daño.
Para la capa de profundidad, la prueba de penetración sigue la metodología Ethical Hacking Test (EHT), con reconocimiento, explotación manual, encadenamiento de fallas y prueba de impacto alineados con OWASP, PTES y NIST SP 800-115. Cada hallazgo viene con prueba de concepto reproducible, priorización por riesgo y retest para validar las correcciones. La elección de la modalidad — red, API, cloud, mobile o Red Team — depende de lo que la empresa necesita probar; para entender en qué se diferencia un ejercicio de Red Team de un pentest con alcance definido, vea nuestra guía completa sobre Red Team y simulación de adversario.
Las empresas con obligaciones regulatorias suelen integrar estas capas a rutas de conformidad como PCI DSS, ISO/IEC 27001 y adecuación a la LGPD. Como empresa de seguridad de la información en São Paulo, ajustamos la cadencia de escaneo y la periodicidad de las pruebas al riesgo de cada operación — para que la inversión refleje lo que necesita protección, y no una tabla genérica.
Preguntas frecuentes
¿Un escáner de vulnerabilidades sustituye al pentest?
No. El escáner encuentra fallas conocidas de forma automatizada y a gran escala, pero no confirma si son explotables, no encadena debilidades y no entiende la lógica de negocio. El pentest explota activamente el objetivo y prueba el impacto real, con prueba de concepto reproducible para cada hallazgo validado.
¿Con qué frecuencia debo ejecutar cada uno?
La gestión de vulnerabilidades es continua: escaneos recurrentes (mensual como piso) y verificación ante cada cambio significativo. El pentest es periódico y orientado a eventos: al menos anual para sistemas críticos, y siempre después de cambios relevantes o antes de lanzamientos. Normas como PCI DSS definen mínimos obligatorios para ambos.
¿Por dónde empezar si el presupuesto es limitado?
Empiece por el inventario y una rutina de escaneo autenticado — sin saber qué tiene, ninguna inversión se justifica. Con lo básico corregido, contrate un pentest enfocado en los activos más críticos y expuestos. Así la prueba, más costosa, se concentra en lo que exige inteligencia humana y no en lo que un escáner resolvería.