Priorización de vulnerabilidades: qué son CVE, CVSS, EPSS, KEV y SSVC

Diferencia entre CVE, CVSS, EPSS y KEV, explicada con un edificio

Piensa en tu empresa como un piso completo dentro de un edificio corporativo. Tiene una recepción que da al pasillo común, oficinas para cada área (gerencia, finanzas, ventas), una sala de servidores y una bodega. Cada puerta tiene una cerradura, y las cerraduras son el software y los equipos que usas: el firewall, el correo, el sitio web, los computadores.

Cuando un fabricante descubre que un modelo de cerradura tiene un defecto, eso es una vulnerabilidad. Cada herramienta responde una pregunta distinta sobre ese defecto:

CVE: ¿de qué defecto hablamos?

El código que el fabricante le asigna al defecto de ese modelo de cerradura. Todos los edificios que la usan saben de cuál se habla.

CVSS: ¿cuánto daño podría causar?

Qué tan fácil se abre y qué se puede hacer adentro. Si se abre con cualquier tarjeta y da acceso a todo el piso, es un 9 o un 10.

EPSS: ¿qué tan probable es que la ataquen?

El pronóstico del jefe de guardias: qué tan probable es que este mes alguien intente abrir ese modelo.

KEV y CSIRT: ¿la están usando hoy?

El aviso de la administración del edificio: ya entraron a otras oficinas usando ese defecto.

SSVC: ¿la cambio hoy, esta semana o en la próxima mantención?

El protocolo de seguridad de tu empresa para decidir qué hacer con esa cerradura.

A eso se suman dos preguntas que solo tu empresa puede responder:

¿Dónde está la puerta?

No es lo mismo la puerta de la recepción, que da al pasillo común por donde pasa cualquiera, que la de una sala interior. Eso es la exposición a internet. Ojo con los computadores de los trabajadores: son como el personal que recibe paquetes y visitas. Aunque estén adentro, están en contacto con el exterior todo el día.

¿Qué hay detrás?

No es lo mismo la oficina de finanzas, con los datos de clientes y las cuentas bancarias, que la sala de reuniones. Eso es la criticidad del activo.

¿Qué es un CVE?

Un CVE (Common Vulnerabilities and Exposures) es el código único que recibe cada vulnerabilidad conocida públicamente. Funciona como un RUT: permite que fabricantes, agencias y equipos de TI hablen de la misma falla sin confusión.

Tiene el formato CVE-año-número. Por ejemplo, CVE-2026-109618 es una de las fallas críticas de PHP publicadas en octubre de 2026.

El CVE solo identifica la falla y describe qué afecta. No dice si es grave ni si la están atacando. Para eso están las herramientas que siguen.

Se consulta en cve.org, en los avisos de cada fabricante y en las alertas del CSIRT Nacional.

¿Qué es CVSS y por qué no basta para priorizar?

El CVSS (Common Vulnerability Scoring System) es una nota de 0 a 10 que mide qué tan grave sería una vulnerabilidad si alguien la aprovecha. Lo mantiene FIRST, una organización internacional de equipos de respuesta a incidentes. De 9,0 a 10,0 es crítica; de 7,0 a 8,9, alta; de 4,0 a 6,9, media, y de 0,1 a 3,9, baja.

Para calcularla se consideran preguntas como: ¿se puede atacar desde internet?, ¿el atacante necesita un usuario?, ¿puede robar datos, modificarlos o detener el servicio?

Su limitación es que la nota que se publica normalmente es la nota base. Describe lo peor que podría pasar, pero no dice si alguien está atacando la falla. En 2026 eso se volvió un problema evidente: Microsoft calificó como críticas 75 vulnerabilidades solo en octubre. Cuando decenas de fallas tienen 9 o más en el mismo mes, la nota deja de servir para ordenar.

La versión 4.0 del CVSS permite ajustar la nota con información de amenazas y del entorno de cada empresa, pero pocas organizaciones lo hacen. En la práctica, el CVSS sirve como un dato más, no como el criterio principal.

¿Qué es EPSS y cómo se interpreta?

El EPSS (Exploit Prediction Scoring System) estima la probabilidad de que una vulnerabilidad sea atacada en los próximos 30 días. También lo mantiene FIRST, y se calcula con un modelo estadístico que usa datos de ataques reales, código de ataque publicado y otras señales. Se actualiza todos los días.

Entrega dos números:

Probabilidad

De 0 a 1. Un EPSS de 0,80 significa un 80% de probabilidad estimada de ataque en los próximos 30 días.

Percentil

Indica cómo se compara con el resto. Un percentil 95 significa que es más probable que el 95% de las vulnerabilidades conocidas.

Su limitación es que es un pronóstico, no una confirmación. Reacciona con algo de retraso cuando una falla nueva empieza a atacarse, y no mide el daño. Un EPSS bajo no significa que la falla sea segura.

Para usarlo, cada empresa define desde qué valor una falla se trata como urgente. Un punto de partida razonable es una probabilidad sobre 10%, porque la gran mayoría de las vulnerabilidades tiene valores muy por debajo. Lo importante es que el umbral quede escrito en la política.

Se consulta en first.org/epss y en la mayoría de las herramientas de gestión de vulnerabilidades.

¿Qué es el catálogo KEV de CISA?

El KEV (Known Exploited Vulnerabilities) es una lista pública de la CISA, la agencia de ciberseguridad de Estados Unidos, que solo incluye vulnerabilidades ya usadas en ataques reales. Para entrar, una falla debe cumplir tres condiciones: tener un CVE asignado, contar con evidencia confiable de explotación real y tener una acción clara para corregirla, como un parche o una medida del fabricante.

Es la señal más fuerte que existe: no es un pronóstico, es un hecho confirmado. Esa confirmación toma tiempo, y es a propósito: CISA solo agrega una falla cuando tiene evidencia confiable. Por eso el KEV no siempre es el primero en avisar. Con las fallas de PHP de octubre de 2026, por ejemplo, ya había intentos de ataque reportados mientras aún no figuraban en el catálogo.

Se consulta en el catálogo KEV de CISA.

Alertas de vulnerabilidades del CSIRT Nacional de Chile

El CSIRT Nacional, que depende de la Agencia Nacional de Ciberseguridad (ANCI), publica alertas de vulnerabilidades críticas y de campañas activas pensadas para la realidad local. Conviene revisarlas junto con el KEV, porque a veces llegan antes. Para reportar incidentes o hacer consultas, la ANCI mantiene el teléfono 1510 y el correo ayuda@anci.gob.cl.

Se consultan en las alertas del CSIRT Nacional.

¿Qué es SSVC y cómo decide qué parchar?

SSVC (Stakeholder-Specific Vulnerability Categorization, o clasificación de vulnerabilidades según el afectado) es un árbol de decisión que dice qué hacer con cada vulnerabilidad, en vez de darle una nota. Lo desarrolló el Software Engineering Institute de la Universidad Carnegie Mellon, y CISA publicó su propia versión en 2022.

Volviendo al edificio: el CVSS, el EPSS y el KEV son informes. El SSVC es el protocolo que usa el jefe de seguridad para decidir, con esos informes en la mano, qué hace con cada puerta.

La versión de CISA responde cinco preguntas:

Explotación

¿No hay evidencia, existe una prueba de concepto pública o ya se está atacando?

Impacto técnico

Si la explotan, ¿el atacante obtiene control parcial o total del sistema?

Automatizable

¿Se puede explotar de forma masiva y automática?

Importancia para la misión

¿Qué tan importante es el sistema afectado para la organización?

Impacto en el bienestar público

¿Cuánto afectaría a personas fuera de la organización?

Según las respuestas, el árbol entrega una de cuatro decisiones:

Act

Actuar lo antes posible, con participación de la alta dirección.

Attend

Atender antes del ciclo normal e informar a las jefaturas.

Track*

Seguir el ciclo normal, pero vigilando de cerca porque puede escalar.

Track

No requiere acción inmediata; sigue el ciclo normal de parches.

Su gran aporte es que la misma falla puede recibir decisiones distintas en dos empresas, según la importancia del sistema afectado para cada una. CISA ofrece una calculadora SSVC gratuita en su sitio.

Cómo priorizar vulnerabilidades: matriz de cuatro cuadrantes

SSVC es completo, pero para una empresa mediana puede ser mucho al comienzo. Por eso en Brumaz usamos una versión simplificada, con dos preguntas por cada vulnerabilidad: ¿está siendo explotada? y ¿el equipo afectado está expuesto a internet? Con eso cada falla cae en uno de cuatro cuadrantes.

Cómo usar cada herramienta dentro de la matriz:

KEV y CSIRT

Responden la primera pregunta. Si la falla aparece en cualquiera de los dos, se considera explotada.

EPSS

Sirve para anticiparse. Una falla sobre el umbral que definiste se trata como si ya estuviera explotada.

La criticidad del activo

Ordena dentro de cada cuadrante y puede subir una falla de cuadrante. Un servidor con datos de clientes o el ERP pesan más que un sitio informativo.

CVSS

Desempata entre fallas parecidas.

Cuentan como expuestos a internet los firewalls, las VPN, el correo, los accesos remotos, los sitios web y cualquier servicio publicado hacia afuera. También los computadores de los usuarios cuando la falla se activa al abrir un correo, un archivo o una página web, porque eso hacen todo el día: una falla que se activa con un clic está, en la práctica, expuesta.

¿En cuántos días hay que parchar una vulnerabilidad crítica?

Los plazos de la matriz son una propuesta. Para compararlos, estas son dos referencias conocidas:

3 días

El plazo que CISA dio a las agencias de Estados Unidos por la falla explotada de BeyondTrust, en octubre de 2026.

1 mes desde que sale el parche

Lo que exige PCI DSS 4.0.1, en su requisito 6.3.3, para las vulnerabilidades críticas.

Para lo interno que no está siendo explotado, el cuadrante 4, nuestra guía de gestión de vulnerabilidades propone como punto de partida 30 días para críticas y 90 para altas. Cada empresa debe ajustar sus plazos y dejarlos escritos en su política.

Correr con un parche también tiene riesgos. Para los cuadrantes 1 y 2 conviene tener definido de antemano un procedimiento de cambio de emergencia: quién autoriza, qué pruebas mínimas se hacen y cómo volver atrás si algo falla.

Ejemplo de priorización de vulnerabilidades con casos reales

Tres vulnerabilidades reales de octubre de 2026 muestran por qué la nota CVSS sola no basta. Supongamos una empresa con un sitio web en PHP, computadores con Windows y un servidor Windows que reparte las direcciones de la red interna (DHCP).

La falla con la nota más alta, 9,8, queda al final. Las que ya se están usando en ataques van primero, aunque su nota sea menor.

Que sea interno no significa que sea irrelevante: si un atacante ya entró a la red, un servidor DHCP vulnerable le permite moverse por ella. Por eso va en el ciclo normal, no en la lista de excepciones.

Entre las dos del cuadrante 1 decide la criticidad del activo. Si el sitio web guarda datos de clientes, va primero. Si es solo informativo, van primero los computadores.

Si mañana apareciera código de ataque público para la de 9,8, su EPSS subiría y habría que moverla de cuadrante. Por eso la clasificación se revisa cada semana.

¿Qué hacer cuando una vulnerabilidad no se puede parchar?

Siempre habrá equipos que no se pueden actualizar a tiempo: sistemas sin soporte, equipos industriales o aplicaciones de proveedores. Las opciones son mitigar con otro control o aceptar el riesgo por escrito, y las explicamos en detalle en la guía de gestión de vulnerabilidades.

Para lo que ya se está explotando hay un paso extra: después de corregir, revisar si alguien entró antes. Si hubo un incidente y tu empresa es prestador de servicios esenciales u operador de importancia vital, la Ley 21.663 exige reportarlo a la ANCI en plazos cortos.

Checklist de priorización de vulnerabilidades

Usa esta lista para revisar si tu empresa está priorizando bien:

Inventario y exposición

Tenemos un inventario actualizado de equipos y sistemas, con su versión, y sabemos cuáles están expuestos a internet y cuáles son críticos para el negocio.

Fuentes y umbral

Alguien revisa cada semana el catálogo KEV y las alertas del CSIRT Nacional, y usamos EPSS, o una herramienta que lo incluya, con un umbral definido.

Política y emergencias

Nuestra política de parches ordena por explotación, exposición y criticidad, no solo por CVSS, y tenemos un procedimiento de cambio de emergencia para parchar fuera de la ventana mensual.

Verificación y registro

Verificamos con un nuevo escaneo que cada parche quedó aplicado, medimos cuántas vulnerabilidades explotadas se corrigieron dentro del plazo y registramos las excepciones, con responsable y fecha de revisión.

Preguntas frecuentes