Gestión de superficie de ataque basada en CVE: madurez 2025
Actualizado: 2026-05-03
La gestión de superficie de ataque basada en CVE ha cambiado más en los últimos tres años que en los quince anteriores. Hasta 2022 la mayoría de equipos vivía con una hoja de cálculo de vulnerabilidades, un escáner que la rellenaba cada semana y una discusión interminable sobre a quién tocaba parchear qué. Hoy esa foto ha mutado: EPSS aporta probabilidad de explotación, el catálogo KEV marca lo que ya está siendo usado contra empresas reales y el contexto de exposición pesa más que el puntaje CVSS. Este artículo recoge qué ha cambiado, qué sigue doliendo y cómo se ve una práctica adulta.
Puntos clave
- CVSS solo mide gravedad teórica, no probabilidad real de explotación: usar CVSS como único filtro genera miles de falsos críticos.
- EPSS (Exploit Prediction Scoring System) asigna probabilidad diaria de explotación en 30 días; filtrar por EPSS > 0.1 reduce el inventario de críticos un 70-80%.
- El catálogo KEV de CISA (~1.300 entradas) marca CVE confirmadas como explotadas activamente: urgencia absoluta, no estadística.
- El contexto de exposición (internet vs. red interna, autenticación, WAF) es el multiplicador que convierte puntaje en riesgo real.
- Los SBOM (SPDX, CycloneDX) permiten cruzar CVE nuevas contra componentes desplegados en segundos, sin esperar el siguiente ciclo de escaneo.
El problema de CVSS solo
Durante muchos años CVSS fue el lenguaje común para hablar de gravedad de CVE. Un puntaje de 9.8 era crítico, un 4.3 era medio, y los equipos intentaban cerrar primero los más altos. El problema es que CVSS mide gravedad teórica en condiciones de explotación ideales, no probabilidad real ni impacto en tu entorno concreto.
Una vulnerabilidad con CVSS 9.8 que requiere acceso local a un servicio interno no expuesto es muchísimo menos urgente que una CVSS 7.5 con exploit público circulando contra un servicio de cara a internet.
La consecuencia de usar CVSS como único filtro fue previsible:
- Miles de vulnerabilidades etiquetadas como críticas.
- Equipos ahogados intentando cerrar todo.
- Tasa real de explotación del inventario que no se correspondía con el orden que indicaba el escáner.
Varios estudios publicados entre 2021 y 2023 mostraron que menos del 5% de las CVE publicadas cada año se explotan en la práctica, y que el CVSS base correlaciona mal con esa probabilidad.
EPSS como capa de probabilidad
La pieza que más ha cambiado la conversación es el Exploit Prediction Scoring System (EPSS), mantenido por FIRST desde 2021 y estabilizado en su versión 3 a mediados de 2023. EPSS asigna a cada CVE una probabilidad entre 0 y 1 de que sea explotada en los próximos treinta días, basada en señales públicas como:
- Menciones en GitHub.
- Aparición en exploit databases.
- Tráfico de escaneo.
- Varios cientos de características adicionales.
La actualización es diaria.
El efecto práctico de mirar EPSS junto a CVSS es inmediato. En proyectos que he acompañado, filtrar por EPSS mayor que 0.1 reduce el inventario de críticos entre un 70 y un 80% sin perder realismo de riesgo, y libera al equipo para ocuparse del resto con tiempo de respiro.
La crítica válida a EPSS es que sus señales son sesgadas hacia lo que se discute públicamente. Una vulnerabilidad explotada por un grupo silencioso contra objetivos concretos puede permanecer con EPSS bajo durante mucho tiempo. EPSS es buena señal estadística, no garantía individual.
El catálogo KEV de CISA
La segunda pieza indispensable es el catálogo Known Exploited Vulnerabilities de CISA, que lleva desde noviembre de 2021 publicando CVE confirmadas como explotadas contra organizaciones. Contiene alrededor de 1.300 entradas acumuladas con actualizaciones varias veces por semana cuando hay campañas activas.
La lógica de uso es simple: si una CVE aparece en KEV, el argumento a favor de parchearla en plazo corto es concluyente. No es probabilidad, es evidencia de uso.
Combinar KEV con EPSS y CVSS da una matriz útil:
| Señal | Tipo | Acción |
|---|---|---|
| KEV | Urgencia absoluta | Escalar inmediatamente |
| EPSS alto (>0.5) | Urgencia estadística | Parchear en semanas |
| CVSS alto sin los anteriores | Trabajo planificable | Ciclo normal |
Esta estratificación es lo que yo llamo una práctica adulta: no una lista ordenada por puntaje único, sino tres colas distintas con plazos distintos.
Contexto de exposición como multiplicador
El tercer componente es donde más equipos siguen fallando: contextualizar la vulnerabilidad en el entorno propio. Una CVE de OpenSSL en un servidor expuesto a internet con tráfico de clientes desconocidos no es lo mismo que la misma CVE en un servicio interno detrás de tres capas de red. Los escáneres tradicionales dan el mismo peso a ambos, y eso distorsiona la priorización.
La respuesta es enriquecer cada CVE detectada con señales de exposición:
- ¿El activo afectado está expuesto a internet o solo en red interna?
- ¿Hay segmentación adicional?
- ¿El servicio requiere autenticación?
- ¿El proceso corre como root o con privilegios limitados?
- ¿Hay un WAF o bouncer delante?
En uno de los entornos que gestiono, tras cruzar CVE detectadas con exposición real, el inventario de vulnerabilidades de máxima prioridad bajó de más de cuatrocientas a unas treinta. No porque las otras no existieran, sino porque estaban en contextos donde el impacto práctico era mínimo.
El papel del SBOM
Tener SBOMs generados en la cadena de construcción, en formato SPDX o CycloneDX, permite cruzar CVE nuevas contra componentes ya desplegados sin tener que escanear binarios en caliente. El beneficio operativo es enorme: cuando aparece una CVE contra una biblioteca ampliamente usada, una consulta al almacén de SBOMs responde en segundos qué artefactos la contienen y en qué versión, en lugar de tener que esperar al siguiente ciclo de escaneo.
Mi recomendación a equipos nuevos: no pelear por el formato en la primera iteración. SPDX, CycloneDX, JSON, lo que más fácilmente genere la cadena de construcción. Lo importante es tener SBOMs de todo lo que se despliega y poder consultarlos rápidamente. El tema de SBOM y firma está relacionado con lo que comentamos en la guía de Wolfi como base de contenedores: esa distribución entrega SBOMs por defecto, lo que simplifica esta capa significativamente.
Lo que sigue doliendo
Tres problemas persisten y no se resolverán pronto:
- Fragmentación del inventario. La mayoría de empresas grandes tienen varios equipos con varios escáneres con varios formatos de salida. Unificarlos es un proyecto perpetuo; cada cambio de herramienta implica rehacer la integración con EPSS, KEV y SBOMs.
- Ventana entre publicación de CVE y disponibilidad de parche. En muchos componentes open source, especialmente los mantenidos por equipos pequeños, pueden pasar semanas entre el anuncio y el parche oficial. Durante esa ventana, los equipos están en posición defensiva: mitigaciones de configuración, reglas de WAF, segmentación.
- Ruido de falsos positivos. Los escáneres basados en versión producen alertas erróneas cuando una distribución Linux ha retroportado el parche sin cambiar la versión pública del paquete.
Conclusión
La gestión de superficie de ataque basada en CVE madura pasa por tres capas: EPSS para probabilidad, KEV para evidencia de uso activo, y contexto de exposición para impacto real. Los equipos que han adoptado esta práctica tienen menos alertas críticas pero atienden mejor las que aparecen. El consejo concreto para quien empieza: integrar EPSS y KEV primero —son datos públicos, gratuitos y fáciles de integrar en cualquier sistema existente. El trabajo de contexto de exposición y SBOM viene después, cuando la primera capa ya está funcionando.
