En ciberseguridad se habla mucho de vulnerabilidades críticas, CVEs, parches urgentes y explotación activa. Todo eso es importante, pero hay una pregunta previa que muchas organizaciones todavía no tienen completamente resuelta: ¿sabemos realmente qué activos tenemos y qué exposición tienen?
La gestión de vulnerabilidades no empieza cuando aparece un informe con cientos o miles de hallazgos. Empieza antes, con un inventario fiable, actualizado y conectado con el contexto real del negocio. Sin esa base, cualquier programa de vulnerabilidades acaba siendo reactivo, incompleto y difícil de priorizar.
En entornos híbridos, este reto se complica todavía más. Hoy las organizaciones conviven con infraestructura on-premise, servicios cloud, sedes remotas, usuarios en movilidad, aplicaciones SaaS, terceros conectados, activos temporales y servicios publicados en Internet. El perímetro ya no es una línea clara. Es un conjunto cambiante de activos, conexiones y exposiciones.
Ahí es donde el asset discovery se convierte en una pieza clave. Su función es identificar qué existe realmente en la infraestructura: servidores, endpoints, dispositivos de red, máquinas virtuales, servicios activos, aplicaciones, bases de datos, recursos cloud o sistemas expuestos. El objetivo no es solo “tener una lista”, sino entender qué activos forman parte de la superficie de ataque.
El problema aparece cuando se confía únicamente en lo que detecta un scanner. Un escáner de vulnerabilidades es una herramienta necesaria, pero no siempre ve todo. Puede dejar fuera equipos apagados en el momento del análisis, segmentos de red no alcanzables, servicios filtrados por firewall, activos fuera de dominio, máquinas desplegadas temporalmente en cloud o sistemas gestionados por terceros.
Y lo que no se ve, normalmente no se parchea, no se monitoriza y no se protege correctamente.
Un ejemplo sencillo: una organización puede tener todos sus servidores corporativos incluidos en el ciclo de análisis mensual, pero dejar fuera una aplicación publicada en Internet por un proveedor, una máquina antigua usada para integraciones o un entorno de pruebas que terminó quedándose en producción. Si ese activo tiene una vulnerabilidad explotable, el riesgo existe, aunque no aparezca en el informe oficial.
Por eso, el inventario no debe entenderse como una hoja Excel que se actualiza una vez al año. Debe ser un proceso continuo, alimentado por distintas fuentes: escáneres de red, herramientas EDR, CMDB, cloud, firewall, DNS, directorio activo, soluciones de exposición externa y datos de negocio. Cuantas más fuentes se crucen, menos zonas ciegas quedan.
El beneficio para el cliente es directo: mayor visibilidad, menor superficie de ataque y más capacidad para tomar decisiones basadas en riesgo real. Para el usuario final, aunque no siempre lo vea, esto se traduce en servicios más estables, menos interrupciones, menor probabilidad de incidentes y mejor protección de sus datos.
La segunda parte del problema es la priorización. Muchas organizaciones siguen gestionando vulnerabilidades casi exclusivamente por CVSS. El CVSS es útil porque ofrece una puntuación técnica común, de 0 a 10, sobre la severidad de una vulnerabilidad. Pero no debe ser el único criterio.
Una vulnerabilidad crítica en un servidor aislado, sin exposición externa y con controles compensatorios, puede no ser tan urgente como una vulnerabilidad media en una aplicación publicada en Internet, con credenciales débiles, datos sensibles y explotación conocida.
La priorización eficaz debe tener en cuenta más variables: exposición real, criticidad del activo, facilidad de explotación, existencia de exploits públicos, presencia en catálogos como CISA KEV, impacto en negocio, datos tratados por el sistema y controles de seguridad existentes. CISA recomienda usar su catálogo de vulnerabilidades explotadas conocidas como una entrada dentro del marco de priorización de vulnerabilidades, precisamente porque no todas las vulnerabilidades con la misma puntuación tienen el mismo riesgo real.
Los datos también refuerzan esta idea. Según Verizon DBIR 2024, la explotación de vulnerabilidades como vía inicial de entrada casi se triplicó respecto al año anterior y representó el 14% de las brechas analizadas. Además, IBM estimó en 2024 que el coste medio global de una brecha alcanzó los 4,88 millones de dólares, con un incremento del 10% respecto al año anterior.
Esto no significa que todas las empresas vayan a sufrir ese impacto, pero sí deja clara una cosa: gestionar mal la exposición tiene consecuencias reales. No es solo un problema técnico. Puede afectar a operación, reputación, cumplimiento, continuidad de negocio y confianza del cliente.
Un enfoque maduro de vulnerabilidades debería responder a preguntas muy concretas:
¿Qué activos tengo?
¿Cuáles están expuestos a Internet?
¿Cuáles soportan procesos críticos?
¿Qué vulnerabilidades están siendo explotadas activamente?
¿Qué sistemas tienen datos sensibles?
¿Qué parches reducen más riesgo en menos tiempo?
¿Qué excepciones están aceptadas y durante cuánto tiempo?
Cuando se trabaja así, el área de seguridad deja de entregar únicamente listados interminables de vulnerabilidades y empieza a aportar criterio. No se trata de decir “hay 2.000 vulnerabilidades pendientes”, sino de indicar cuáles son las 20 que realmente pueden comprometer el negocio si no se corrigen.
Ese cambio es clave para no morir en el intento. Los equipos técnicos tienen recursos limitados, ventanas de cambio reducidas y servicios que no pueden parar constantemente. Por eso, la gestión de vulnerabilidades debe ser realista, priorizada y accionable.
La conclusión es sencilla: no se trata de parchearlo todo al mismo tiempo, sino de parchear primero lo que más reduce el riesgo.
Una buena gestión de inventario y vulnerabilidades permite pasar de una seguridad reactiva a una seguridad basada en contexto. Menos ruido, más visibilidad y mejores decisiones.
Porque en ciberseguridad, lo que no se ve también puede atacarse. Y lo que no se prioriza correctamente acaba compitiendo con todo lo demás hasta que ya es demasiado tarde.