La mayoría de las empresas no tiene un problema de falta de escaneos. Tiene un problema de priorización.
Un escáner puede entregar cientos o miles de vulnerabilidades. Muchas aparecerán marcadas como críticas o altas. Algunas afectarán a activos internos con bajo impacto. Otras estarán en sistemas expuestos a Internet, con explotación activa, credenciales asociadas, acceso a datos sensibles o capacidad de movimiento lateral.
Tratar todas igual es inviable. Tratar solo las de CVSS más alto también es peligroso.
La gestión moderna de vulnerabilidades necesita responder a una pregunta más útil: ¿qué vulnerabilidades tienen más probabilidad de convertirse en incidente real en nuestro contexto?
Para hacerlo bien, conviene combinar varias señales: CISA KEV, EPSS, SSVC, CVSS, exposición, criticidad del activo, explotación observada, facilidad de remediación, controles compensatorios y posible impacto de negocio.
No es teoría. CISA mantiene el catálogo KEV como una referencia de vulnerabilidades conocidas explotadas en la práctica, orientada a ayudar a organizaciones a gestionar vulnerabilidades y seguir el ritmo de la actividad real de amenaza. FIRST define EPSS como un modelo de machine learning que estima la probabilidad de que una CVE publicada sea explotada en los siguientes 30 días. Y CISA usa SSVC como una metodología de decisión para clasificar vulnerabilidades según factores como explotación, impacto y contexto operativo.
La idea de fondo es sencilla: CVSS mide severidad técnica. KEV confirma explotación real. EPSS estima probabilidad de explotación. SSVC ayuda a decidir qué hacer.
Por qué CVSS no basta
CVSS sigue siendo útil. Ayuda a entender la severidad técnica de una vulnerabilidad y permite una primera clasificación. El problema aparece cuando se usa como único criterio.
Una CVE con CVSS 9.8 puede estar en un sistema aislado, compensado, sin exposición externa y con bajo impacto real para la organización. Otra CVE con CVSS 7.5 puede estar en una VPN, un firewall, una aplicación publicada, un servidor con credenciales privilegiadas o un sistema que da acceso a datos críticos.
En la práctica, la segunda puede ser más urgente.
CVSS responde a la pregunta: “¿qué tan grave es esta vulnerabilidad en términos técnicos?”. No responde por sí solo a estas otras preguntas:
¿Está siendo explotada activamente?
¿Afecta a un activo expuesto a Internet?
¿Existe exploit público?
¿Permite acceso inicial?
¿Permite escalar privilegios?
¿Está en un sistema crítico?
¿Compromete identidad, sesiones, tokens o datos sensibles?
¿Hay controles que reduzcan el riesgo?
¿Se puede parchear sin romper operación?
¿Existe una mitigación temporal fiable?
Por eso una gestión de vulnerabilidades seria no puede limitarse a ordenar hallazgos por CVSS y enviar un Excel.
Qué es CISA KEV y por qué debería estar en tu proceso
El catálogo Known Exploited Vulnerabilities, conocido como KEV, recoge vulnerabilidades con evidencia de explotación en el mundo real. CISA lo mantiene como fuente de referencia para defensores y responsables de seguridad.
Su valor es muy directo. Si una vulnerabilidad aparece en KEV, ya no estamos hablando solo de posibilidad. Hablamos de explotación observada.
En un proceso empresarial, KEV debería funcionar como una señal de urgencia. No significa que todas las vulnerabilidades KEV tengan exactamente el mismo impacto en tu organización, pero sí significa que no deberían quedarse enterradas en un backlog genérico.
Una regla práctica sería:
Si una vulnerabilidad está en KEV y afecta a un activo expuesto o crítico, debe entrar en circuito urgente.
Si está en KEV, pero afecta a un activo no expuesto y con controles compensatorios fuertes, puede requerir una ventana prioritaria, pero documentada.
Si está en KEV y no sabes si te afecta, el problema no es solo la vulnerabilidad. El problema es el inventario.
Ese último punto es clave. Muchas organizaciones no tardan en parchear porque no quieran. Tardan porque no saben con certeza si tienen el producto, qué versión ejecutan, dónde está desplegado o quién es el dueño del activo.
Qué es EPSS y cómo ayuda a priorizar
EPSS no sustituye a CVSS ni a KEV. Aporta otra señal.
FIRST define EPSS como un modelo basado en datos que estima la probabilidad de que una CVE publicada sea explotada en la práctica durante los siguientes 30 días.
Esto cambia la conversación.
Una vulnerabilidad puede ser técnicamente grave, pero tener baja probabilidad de explotación inmediata. Otra puede no parecer la más grave del informe, pero tener una probabilidad alta de explotación porque ya hay actividad, interés de atacantes, PoC pública, patrones históricos o señales externas.
EPSS ayuda a priorizar cuando hay demasiadas vulnerabilidades y recursos limitados.
Ejemplo práctico:
La tabla no decide sola. Pero evita un error común: tratar la puntuación CVSS como si fuera riesgo empresarial.
Qué es SSVC y por qué aporta criterio de decisión
SSVC significa Stakeholder-Specific Vulnerability Categorization. Es una metodología de priorización basada en árboles de decisión. Su objetivo es ayudar a tomar decisiones adaptadas al contexto del stakeholder, evitando una respuesta única para todas las vulnerabilidades. CISA explica que su modelo se apoya en criterios como explotación, impacto y prevalencia del producto afectado.
SSVC es especialmente útil porque obliga a convertir señales técnicas en decisiones operativas.
No se queda en “crítica”, “alta”, “media” o “baja”. Permite llegar a acciones como:
- actuar inmediatamente,
- actuar en ventana prioritaria,
- programar remediación,
- monitorizar,
- aceptar temporalmente con justificación,
- aplicar mitigación compensatoria,
- escalar a dirección por impacto operativo.
En empresas reales, esto importa mucho. No todo se puede parchear en 24 horas. Hay sistemas productivos, proveedores, ventanas de cambio, entornos regulados, dependencias, validaciones y riesgo de caída.
SSVC ayuda a decidir mejor cuando hay tensión entre seguridad y continuidad.
Modelo práctico para priorizar vulnerabilidades
Una empresa puede construir un modelo de priorización bastante sólido combinando siete dimensiones.
1. Explotación observada
La primera pregunta debería ser:
¿Está siendo explotada activamente?
Fuentes útiles:
- CISA KEV.
- Inteligencia de amenazas.
- Información de fabricantes.
- Informes de CERT.
- Telemetría propia.
- Actividad vista por SOC.
- Indicadores de campañas activas.
- Explotación observada en honeypots o fuentes sectoriales.
Si hay explotación activa, el hallazgo sube de prioridad. Si además afecta a un sistema expuesto, sube mucho más.
2. Probabilidad de explotación
Aquí entra EPSS.
No todas las CVEs no explotadas tienen la misma probabilidad de serlo. EPSS permite distinguir vulnerabilidades que probablemente atraigan actividad en los próximos días o semanas.
Una organización puede definir umbrales internos. Por ejemplo:
- EPSS alto: revisión inmediata.
- EPSS medio: priorización según exposición y criticidad.
- EPSS bajo: tratar según CVSS, activo y ventana normal.
No conviene usar EPSS como único criterio. Una vulnerabilidad con EPSS bajo puede ser crítica en un sistema muy sensible. Pero como señal de probabilidad, aporta mucho.
3. Exposición del activo
La misma CVE no pesa igual en todos los activos.
Factores que elevan prioridad:
- Activo expuesto a Internet.
- VPN, firewall, gateway, proxy, balanceador o appliance.
- Servicio accesible por terceros.
- API pública.
- Consola de administración.
- Sistema con acceso a red interna.
- Sistema con credenciales o secretos.
- Activo en DMZ mal segmentada.
- Servicio legacy sin soporte.
Un hallazgo en edge devices suele merecer una revisión más rápida. Google Threat Intelligence destacó en su revisión de zero-days de 2025 el peso de tecnologías empresariales y appliances, con especial relevancia de productos de seguridad y networking.
4. Criticidad de negocio
No todo activo técnico tiene el mismo valor.
Hay que considerar:
- datos personales,
- datos financieros,
- propiedad intelectual,
- sistemas productivos,
- continuidad del negocio,
- acceso a clientes,
- acceso a terceros,
- impacto regulatorio,
- dependencia operacional,
- capacidad de propagación.
Una vulnerabilidad en un sistema financiero, sanitario, industrial o SaaS multi-cliente puede tener un impacto muy distinto a la misma CVE en un laboratorio interno.
Aquí conviene cruzar la gestión de vulnerabilidades con el análisis de riesgos, el inventario de activos y el BIA si existe.
5. Tipo de impacto técnico
La explotación no siempre produce el mismo resultado.
Hay vulnerabilidades que permiten:
- ejecución remota de código,
- bypass de autenticación,
- robo de sesiones,
- escalada de privilegios,
- lectura de ficheros,
- SSRF,
- acceso a credenciales,
- movimiento lateral,
- denegación de servicio,
- manipulación de configuración,
- exposición de datos.
Para priorizar, no basta con mirar la severidad. Hay que entender qué obtiene el atacante.
Una vulnerabilidad de lectura de memoria en un sistema de acceso remoto puede ser más peligrosa de lo que parece si permite extraer tokens, sesiones o credenciales.
6. Existencia de controles compensatorios
No todos los sistemas vulnerables están igual de expuestos.
Pueden existir controles que reduzcan el riesgo:
- segmentación,
- WAF,
- reglas IPS,
- acceso por VPN,
- allowlist de IP,
- MFA,
- EDR,
- hardening,
- logging,
- monitorización SOC,
- desactivación de funcionalidad vulnerable,
- aislamiento temporal,
- bloqueo perimetral.
El error es usar los controles compensatorios como excusa indefinida. Deben servir para ganar tiempo, no para olvidar el parche.
7. Viabilidad de remediación
La priorización también debe mirar la realidad operativa.
Hay que saber:
- si existe parche,
- si el fabricante mantiene soporte,
- si requiere reinicio,
- si afecta a producción,
- si hay dependencia de proveedor,
- si necesita ventana de cambio,
- si puede romper compatibilidad,
- si existe mitigación temporal,
- si el activo debería retirarse,
- si hay que migrar a una versión soportada.
En muchos casos, la decisión correcta no es “parchear”, sino retirar, aislar, segmentar, sustituir o rediseñar.
Árbol de decisión práctico
Un modelo útil para empresas podría ser este:
Nivel 1: Urgente
Aplicar cuando se cumple una o varias condiciones:
- CVE en CISA KEV.
- Explotación activa confirmada.
- EPSS alto y activo expuesto.
- RCE en sistema publicado.
- Bypass de autenticación en VPN, firewall, gateway o SaaS.
- Vulnerabilidad que permite robo de credenciales, tokens o sesiones.
- Activo crítico sin controles compensatorios.
- Evidencia de explotación en logs propios.
Acción recomendada: remediación inmediata, mitigación temporal, hunting, revisión de logs y validación posterior.
Nivel 2: Alta prioridad
Aplicar cuando:
- EPSS alto, aunque no esté en KEV.
- CVSS crítico en activo relevante.
- Sistema expuesto con exploit público.
- Producto muy desplegado en la organización.
- Vulnerabilidad útil para movimiento lateral.
- Activo con datos sensibles, pero con controles parciales.
Acción recomendada: parcheo en ventana prioritaria, validación técnica y seguimiento de cierre.
Nivel 3: Planificada
Aplicar cuando:
- CVSS alto, pero sin explotación conocida.
- EPSS bajo o medio.
- Activo interno no crítico.
- Controles compensatorios razonables.
- Bajo impacto de negocio.
- Remediación requiere ventana formal.
Acción recomendada: incluir en ciclo ordinario, con fecha comprometida y responsable.
Nivel 4: Monitorizar o aceptar temporalmente
Aplicar cuando:
- No hay parche viable.
- El producto está en proceso de retirada.
- Hay controles compensatorios fuertes.
- El activo está aislado.
- El riesgo residual está documentado.
- La remediación puede generar más riesgo operativo que la propia vulnerabilidad a corto plazo.
Acción recomendada: aceptación formal, monitorización, fecha de revisión y plan de eliminación.
Cómo convertir esto en un proceso operativo
La priorización no debe depender de una persona revisando manualmente un Excel cada mes.
Un proceso maduro debería incluir:
- Inventario actualizado de activos.
- Escaneo técnico recurrente.
- Enriquecimiento con KEV, EPSS, CVSS y fuentes de threat intelligence.
- Cruce con exposición externa.
- Cruce con criticidad de negocio.
- Identificación de responsables por activo.
- Clasificación por prioridad.
- Tickets de remediación.
- Validación de cierre.
- Reporting ejecutivo.
- Métricas de evolución.
- Hunting cuando existan señales de explotación.
La parte más importante suele ser la validación. Muchas vulnerabilidades se marcan como cerradas porque “se aplicó el parche”, pero no se comprueba si la versión cambió realmente, si el servicio vulnerable sigue expuesto, si hay instancias duplicadas o si el activo reapareció por otro camino.
Métricas que sí aportan valor
Un comité de dirección no necesita leer todas las CVEs. Necesita ver riesgo y evolución.
Métricas útiles:
- Vulnerabilidades KEV abiertas.
- KEV abiertas en activos expuestos.
- Tiempo medio de remediación de KEV.
- Vulnerabilidades con EPSS alto abiertas.
- Activos expuestos con CVEs críticas.
- Activos sin propietario.
- Sistemas fuera de soporte.
- Vulnerabilidades reabiertas.
- Porcentaje de remediaciones validadas.
- Riesgo por área o unidad.
- Exposición por proveedor.
- Tiempo desde detección hasta ticket.
- Tiempo desde ticket hasta cierre.
- Número de excepciones aceptadas.
- Excepciones vencidas.
- Vulnerabilidades con mitigación temporal.
Estas métricas ayudan a distinguir una organización que escanea mucho de una organización que reduce riesgo.
Ejemplo técnico: cómo priorizar una CVE en VPN
Imaginemos una vulnerabilidad en una VPN corporativa.
CVSS: 8.8.
EPSS: alto.
KEV: no aparece todavía.
Activo: expuesto a Internet.
Impacto: acceso remoto.
Usuarios: empleados y proveedor externo.
Logs: enviados parcialmente al SIEM.
Parche: disponible.
Ventana: requiere reinicio.
Aunque no esté en KEV, la prioridad debería ser alta o urgente. El activo es expuesto, la función es crítica y la explotación afectaría directamente al acceso remoto.
La respuesta no debería limitarse a “programar parche”.
Acciones razonables:
- revisar logs de acceso recientes,
- buscar patrones anómalos,
- aplicar mitigación temporal si existe,
- limitar acceso por geografía o allowlist si es viable,
- revisar cuentas con acceso VPN,
- validar MFA,
- parchear en ventana urgente,
- confirmar versión corregida,
- monitorizar intentos posteriores,
- documentar la actuación.
Esto conecta vulnerabilidades, identidad, SOC y respuesta. Justo lo que suele faltar.
Ejemplo técnico: cómo priorizar una CVE interna
Ahora una vulnerabilidad crítica en un servidor interno.
CVSS: 9.8.
EPSS: bajo.
KEV: no.
Activo: no expuesto.
Segmentación: correcta.
Datos: no sensibles.
Explotación: requiere acceso previo.
Parche: disponible, pero la aplicación es legacy.
Aquí el riesgo no desaparece, pero puede no ser la primera urgencia. La decisión correcta puede ser planificar parcheo, documentar controles y revisar si ese servidor podría convertirse en paso de movimiento lateral.
Si el servidor tiene credenciales privilegiadas, shares sensibles o acceso a sistemas críticos, la prioridad cambia. Por eso el contexto importa.
Error habitual: confundir cumplimiento con reducción de exposición
Cumplir una política de “parchear críticas en 30 días” puede ser insuficiente.
Un atacante no espera 30 días si la vulnerabilidad está explotándose activamente. Tampoco le importa que la CVE sea “solo alta” si le permite acceder a una VPN, robar sesiones o entrar en una aplicación expuesta.
La gestión de vulnerabilidades basada en riesgo debe convivir con compliance, pero no depender solo de él.
Para entornos regulados, esta aproximación encaja especialmente bien con ENS, ISO 27001, NIS2 y DORA, porque permite demostrar no solo que existen controles, sino que se prioriza según exposición, amenaza y criticidad.
Qué papel tiene el SOC
Un SOC no debería ser solo un receptor de alertas. En vulnerabilidades explotables, puede aportar mucho más.
Puede ayudar a:
- detectar intentos de explotación,
- correlacionar CVEs con actividad real,
- identificar explotación previa al parcheo,
- activar hunting sobre activos afectados,
- monitorizar indicadores específicos,
- revisar logs de VPN, firewall, WAF, EDR, M365 y cloud,
- detectar movimiento lateral posterior,
- validar si una CVE ya fue usada como vector inicial.
Cuando una vulnerabilidad crítica afecta a un activo expuesto, la pregunta no es solo “¿hemos parcheado?”. También es “¿alguien la explotó antes de parchear?”.
Ahí entra SOC gestionado 24/7, threat hunting y respuesta a incidentes.
Qué papel tiene threat intelligence
Threat intelligence aporta contexto.
No todas las vulnerabilidades interesan igual a los atacantes. Algunas se explotan de forma masiva. Otras se usan en campañas concretas. Otras afectan a sectores específicos. Otras aparecen en playbooks de ransomware, botnets o grupos estatales.
Un proceso de priorización más maduro debería incorporar:
- explotación observada,
- actores que la usan,
- sectores afectados,
- disponibilidad de PoC,
- facilidad de explotación,
- uso en ransomware,
- uso en botnets,
- explotación contra edge devices,
- actividad geográfica,
- urgencia recomendada por CERT o fabricante.
Esto ayuda a pasar de “vulnerabilidad crítica” a “vulnerabilidad crítica para nosotros”.
Cómo encaja Hard2bit
En Hard2bit, la gestión de vulnerabilidades para empresas no debería entenderse como un escaneo periódico aislado. El valor está en convertir hallazgos técnicos en decisiones accionables.
Eso implica:
- descubrir activos,
- identificar exposición,
- priorizar con criterio técnico,
- cruzar CVSS, KEV, EPSS, contexto y criticidad,
- generar planes de remediación,
- acompañar al equipo técnico,
- validar el cierre,
- alimentar al SOC cuando hay señales de explotación,
- documentar evidencias útiles para auditoría,
- reducir riesgo real, no solo producir informes.
Además, para organizaciones sujetas a ENS, tiene sentido revisar la gestión de vulnerabilidades ENS como una capacidad específica. No basta con decir que se hacen escaneos. Hay que demostrar tratamiento, seguimiento, remediación, evidencias y trazabilidad.
Checklist técnico para implantar priorización KEV + EPSS + SSVC
Inventario
- ¿Existe inventario de activos actualizado?
- ¿Cada activo tiene propietario?
- ¿Se sabe qué activos están expuestos a Internet?
- ¿Se identifican tecnologías, versiones y criticidad?
- ¿Se incluyen cloud, SaaS, M365, APIs, VPN, firewalls y appliances?
Enriquecimiento
- ¿Se cruza cada CVE con CISA KEV?
- ¿Se incorpora EPSS?
- ¿Se mantiene CVSS como señal, no como decisión única?
- ¿Se usa threat intelligence?
- ¿Se identifica exploit público?
- ¿Se detectan vulnerabilidades en productos fuera de soporte?
Priorización
- ¿Existe un árbol de decisión?
- ¿Se diferencia entre urgente, alta prioridad, planificada y aceptada?
- ¿Se considera exposición?
- ¿Se considera criticidad de negocio?
- ¿Se considera impacto técnico?
- ¿Se documentan excepciones?
Remediación
- ¿Cada hallazgo tiene responsable?
- ¿Hay fecha objetivo?
- ¿Se validan cierres?
- ¿Se registran mitigaciones temporales?
- ¿Se reabren hallazgos si reaparecen?
- ¿Se mide tiempo real de remediación?
Detección
- ¿El SOC conoce las CVEs urgentes?
- ¿Se buscan indicadores de explotación?
- ¿Se revisan logs de activos afectados?
- ¿Se hace hunting en vulnerabilidades críticas?
- ¿Se correlacionan vulnerabilidades con alertas?
Reporting
- ¿Dirección ve riesgo agregado?
- ¿Se reportan KEV abiertas?
- ¿Se reportan activos expuestos vulnerables?
- ¿Se reportan excepciones vencidas?
- ¿Se mide reducción de exposición?
- ¿Se diferencia volumen de vulnerabilidades y riesgo real?
La gestión de vulnerabilidades ya no puede basarse solo en CVSS ni en informes mensuales.
El volumen de CVEs, la velocidad de explotación y la presión operativa obligan a priorizar mejor. KEV ayuda a identificar vulnerabilidades explotadas activamente. EPSS aporta probabilidad de explotación. SSVC ayuda a convertir señales técnicas en decisiones. CVSS sigue siendo útil, pero como una pieza más.
El objetivo no es parchear todo al mismo ritmo. El objetivo es reducir primero lo que tiene más probabilidad de convertirse en incidente.
Para lograrlo, hay que unir inventario, exposición, criticidad, inteligencia, SOC, remediación y validación. Esa es la diferencia entre escanear vulnerabilidades y gestionar riesgo técnico de verdad.
¿Quieres priorizar vulnerabilidades con criterio real de riesgo?
En Hard2bit ayudamos a empresas a pasar del escaneo periódico a una gestión de vulnerabilidades basada en exposición, explotación activa, criticidad y remediación verificable.
Podemos ayudarte a identificar qué vulnerabilidades son realmente urgentes, cuáles afectan a activos expuestos, cuáles deben escalarse al SOC y cuáles requieren validación técnica posterior. También trabajamos la gestión de vulnerabilidades ENS para organizaciones que necesitan trazabilidad, evidencias y capacidad de defensa ante auditoría.
Combina este enfoque con SOC gestionado 24/7, threat intelligence, threat hunting y auditoría técnica para reducir exposición real antes de que una CVE se convierta en incidente.