La gestión de vulnerabilidades es el proceso continuo de descubrir las debilidades de seguridad de una organización, decidir cuáles importan de verdad, corregirlas o contenerlas y comprobar que quedaron cerradas. No es un escaneo, no es un informe anual y no es la tarea de aplicar actualizaciones. El parche es una de las salidas posibles del proceso. El proceso es lo que decide cuál de las 190 vulnerabilidades que se publicaron hoy merece que alguien pare lo que está haciendo.
Conviene tomárselo en serio por una razón concreta: por primera vez desde que existe el informe, la explotación de vulnerabilidades es la forma más común de entrar. El DBIR 2026 de Verizon la ubica en el 31% de los accesos iniciales, frente al 20% del año anterior, por encima de las credenciales robadas.
Y mientras eso subía, la capacidad de responder bajó. El mismo informe midió el tiempo que tardan las organizaciones en corregir una vulnerabilidad que ya se sabe que está siendo explotada: la mediana pasó de 32 a 43 días. De las vulnerabilidades del catálogo de explotación conocida, solo el 26% estaba corregido del todo en las 13.000 organizaciones estudiadas. El año anterior era el 38%.
¿Qué incluye el ciclo de gestión de vulnerabilidades?
Cinco etapas que se repiten para siempre. La palabra importante es se repiten: un ciclo que se ejecuta una vez al trimestre y se detiene ahí no es gestión, es una foto vieja.
| Etapa | Qué se hace | El error típico |
|---|---|---|
| 1. Descubrir | Saber qué hay: servidores, equipos, aplicaciones, nube, dispositivos de red, lo que instaló un área sin avisar | Escanear solo lo que ya está en el inventario, que es justo lo que sí se vigila |
| 2. Priorizar | Ordenar los hallazgos por riesgo real para esta empresa, no por la puntuación de gravedad | Atacar todo lo “crítico” a la vez y no terminar ninguna cosa |
| 3. Remediar | Parchear, cambiar una configuración, retirar el sistema o contenerlo con otro control | Asumir que remediar y parchear son sinónimos |
| 4. Verificar | Volver a comprobar que la corrección se aplicó, que el servicio se reinició y que el hallazgo desapareció | Cerrar el ticket cuando el parche se descargó, no cuando el sistema quedó limpio |
| 5. Medir | Seguir cuánto tarda la organización en cerrar por nivel de riesgo y qué porcentaje queda abierto | Reportar cuántas vulnerabilidades se encontraron, que no dice nada del riesgo |
La etapa cinco es la que convierte esto en una disciplina medible. Sin ella nadie puede responder a la única pregunta que hace un director general: si mañana sale algo grave, ¿en cuántos días lo tenemos cerrado?
¿Por qué parchear ya no alcanza?
Porque el parche sigue siendo necesario y dejó de ser suficiente, por cuatro motivos que se acumulan.
El volumen. En el primer semestre de 2026 se publicaron más de 35.000 vulnerabilidades nuevas, un promedio cercano a 190 por día (métricas públicas del programa CVE). El propio NIST reconoció que el envío de vulnerabilidades creció un 263% entre 2020 y 2025 y cambió su forma de trabajar en abril de 2026 para analizar primero las que están siendo explotadas. Si el organismo que cataloga las vulnerabilidades tuvo que priorizar, es raro esperar que un equipo de tres personas las atienda todas.
La velocidad. Aquí está el desajuste real. La organización promedio corrige en 43 días. Del otro lado, un trabajo de la Cloud Security Alliance publicado en abril de 2026, The Collapsing Exploit Window, documenta que hoy se puede generar código de ataque funcional para una vulnerabilidad recién publicada en 10 o 15 minutos y por alrededor de un dólar. El mismo trabajo señala que el 32,1% de los ataques nuevos rastreados en 2025 aparecieron el día de la publicación o antes.
Lo que no se puede parchear. Siempre hay una parte del inventario donde el parche no es una opción a corto plazo: el sistema que sostiene la producción y solo se puede detener en diciembre, la aplicación heredada que el proveedor ya no mantiene, el equipo médico o industrial certificado tal como está, y el servicio en la nube donde el parche lo aplica otro y uno solo espera. Para todo eso hace falta otra cosa.
El parche no cierra lo que ya pasó. Actualizar el software elimina la puerta, no al que ya entró por ella. Si la vulnerabilidad estuvo abierta seis semanas en un equipo expuesto a internet, después de parchear queda una pregunta pendiente, y esa pregunta la responde la detección, no el parche.
¿Cómo se prioriza cuando no se puede corregir todo?
Con tres datos que casi nadie mira juntos, y que en conjunto reducen la lista de miles a decenas.
El primero es la gravedad técnica, la puntuación CVSS del 0 al 10. Es el dato más usado y el más engañoso, porque describe la vulnerabilidad en abstracto y no dice nada de si alguien la está usando.
El segundo es la explotación real. El catálogo KEV de CISA lista las vulnerabilidades que se han visto usadas en ataques reales. Son cientos, no decenas de miles. Cuando algo entra en esa lista deja de ser un hallazgo del escáner y pasa a ser una tarea con fecha. El sistema EPSS, que estima la probabilidad de que una vulnerabilidad se explote en los próximos 30 días, cumple la misma función de filtro.
El tercero es el contexto de la empresa, y es el que ningún proveedor puede darte: dónde está ese sistema, si mira a internet, qué datos toca, si tiene doble factor delante, si hay un respaldo, y qué se detiene si se cae. La misma vulnerabilidad en un servidor de pruebas y en el portal de clientes no es la misma vulnerabilidad.
La regla práctica de las cuatro respuestas
Antes de mover un hallazgo al primer lugar de la fila, cuatro preguntas. Si las cuatro dan que sí, se corrige esta semana, no en el próximo ciclo.
- ¿Está en el catálogo de explotación conocida o ya hay código de ataque público?
- ¿El sistema afectado es accesible desde internet o desde la red de un tercero?
- ¿Toca datos personales, dinero o un proceso que no puede detenerse?
- Si alguien la aprovechara hoy, ¿lo veríamos, o nos enteraríamos por el cliente?
La cuarta pregunta es la que suele cambiar la conversación en el comité. Una vulnerabilidad sin vigilancia encima no es un riesgo pendiente, es un riesgo invisible.
¿Qué se hace cuando el parche no está disponible o no se puede aplicar?
Se aplica un control compensatorio, que es la forma elegante de decir que si no puedes cerrar la puerta, pones a alguien delante. Las cuatro opciones habituales:
- Reducir la exposición. Sacar el servicio de internet, limitarlo a una lista de direcciones conocidas o dejarlo detrás de una VPN. Es la medida más efectiva y casi siempre la más barata.
- Desactivar la función vulnerable. Muchos avisos de seguridad indican qué módulo, puerto o característica concreta se puede apagar mientras llega la corrección.
- Parche virtual. Una regla en el firewall o en el sistema de prevención de intrusiones que bloquea el intento de ataque específico sin tocar la aplicación. Compra semanas.
- Vigilancia reforzada. Aumentar el registro en ese sistema y avisar al SOC de que ese activo está en observación. Es lo mínimo aceptable cuando ninguna de las tres anteriores es posible.
Un control compensatorio siempre es temporal y siempre lleva fecha de revisión. Cuando no la lleva, se convierte en la configuración definitiva y nadie recuerda por qué existe.
¿En qué se diferencia de un escaneo o de un pentesting?
Son tres cosas distintas y se contratan por motivos distintos. El escaneo de vulnerabilidades es una herramienta automática que compara lo que encuentra contra una base de fallas conocidas: es rápido, es barato, se puede correr todas las semanas y produce una lista larga. El pentesting es un ejercicio manual en el que un especialista intenta encadenar varias debilidades hasta lograr algo real, y encuentra lo que ningún escáner ve, como una falla de lógica de negocio. La gestión de vulnerabilidades es el proceso que rodea a los dos: recibe sus hallazgos, los prioriza, los asigna, los persigue y mide cuánto se tardó en cerrarlos.
Dicho de otra forma: el escáner y el pentest producen hallazgos, y los hallazgos no reducen el riesgo. Lo reduce lo que la organización hace con ellos, que es exactamente lo que se mide con el tiempo de respuesta y con el porcentaje de hallazgos críticos que siguen abiertos pasados los treinta días.
Preguntas frecuentes
¿Cada cuánto hay que escanear?
¿Qué es una vulnerabilidad de día cero y cambia la prioridad?
¿Sirve de algo el CVSS entonces?
¿Quién debe ser responsable del proceso en la empresa?
¿Y las vulnerabilidades de mis proveedores de software en la nube?
La lista no es el problema
Casi todas las empresas que revisamos tienen el escáner. Muy pocas pueden decir en cuántos días cierran algo grave, cuántos hallazgos críticos llevan más de un mes abiertos y quién firmó los riesgos que decidieron aceptar. Esa diferencia, entre tener la lista y tener el proceso, es toda la gestión de vulnerabilidades.
En ZetTateK montamos ese proceso y lo sostenemos: descubrimiento continuo, priorización con explotación real y contexto, y un SOC 24/7 que vigila lo que todavía está abierto mientras se corrige. Si quieres saber por dónde empezar, el diagnóstico de seguridad sin costo te dice qué tienes expuesto hoy. Los demás términos de este artículo están en el glosario de ciberseguridad.
Parchear es una tarea. Gestionar vulnerabilidades es decidir, todos los días, qué se corrige primero y qué se vigila mientras tanto.
