Microsoft publica VEX para todos sus CVE: cómo priorizar vulnerabilidades con menos ruido
Microsoft amplía VEX a todos sus CVE. Así puedes combinar sus estados con SBOM, exposición y riesgo para priorizar vulnerabilidades con menos ruido.
Microsoft ha empezado a publicar declaraciones VEX para todos los CVE que asigna, de modo que herramientas y equipos de seguridad puedan interpretar de forma automática si una vulnerabilidad afecta a un producto, sigue en investigación, ya está corregida o no resulta explotable en ese contexto. La medida no sustituye los parches ni convierte una alerta en una decisión automática, pero sí reduce una parte importante del ruido que aparece al cruzar inventarios, SBOM y avisos de seguridad.
Qué ha anunciado Microsoft
El Microsoft Security Response Center comunicó el 8 de septiembre de 2026 que publicará declaraciones VEX para todos los CVE asignados por Microsoft. El cambio amplía un trabajo anterior: la compañía ya publicaba avisos legibles por máquinas mediante CSAF y había empezado a utilizar VEX para vulnerabilidades de componentes de terceros presentes en Azure Linux.
La novedad importante no es que aparezcan más vulnerabilidades ni que Microsoft vaya a distribuir más actualizaciones. Lo que cambia es la forma estructurada de comunicar la relación entre un CVE y los productos concretos. Una plataforma de gestión puede consumir esa información sin depender únicamente de una página redactada para personas, una expresión regular o una clasificación manual.
Qué es VEX y qué estados comunica
VEX, siglas de Vulnerability Exploitability eXchange, es una forma estandarizada de expresar si una vulnerabilidad concreta tiene impacto en un producto determinado. Resulta especialmente útil cuando un inventario o una SBOM detecta una biblioteca vulnerable, pero eso no basta para concluir que la aplicación final sea explotable.
Un componente puede estar presente sin que se utilice la función vulnerable, puede compilarse con una opción distinta o quedar aislado por una condición del producto. También puede ocurrir lo contrario: que el producto sí esté afectado y necesite una corrección concreta. VEX permite que el proveedor publique esa valoración de forma procesable.
| Estado VEX | Qué comunica | Respuesta operativa razonable |
|---|---|---|
| Known affected | El producto está afectado por la vulnerabilidad. | Validar exposición, mitigación y calendario de corrección con prioridad. |
| Fixed | Existe una versión o condición en la que el problema está corregido. | Comprobar la versión instalada y desplegar la actualización según el riesgo. |
| Under investigation | El proveedor todavía está evaluando el impacto. | Mantener seguimiento, aplicar controles temporales y evitar cerrar la alerta. |
| Not affected | El producto no resulta afectado en las condiciones declaradas. | Conservar la justificación y verificar que coincide con la versión y configuración reales. |
El matiz de la última columna es decisivo. «No afectado» no significa «ignorar para siempre»: significa que el proveedor aporta una afirmación para un producto, una versión y unas condiciones. La automatización debe conservar esa relación y no convertirla en una excepción global para cualquier equipo donde aparezca el mismo componente.
Qué aporta VEX y qué no resuelve por sí solo
El beneficio principal es reducir el tiempo dedicado a interpretar alertas que carecen de contexto de producto. En organizaciones con muchos equipos, servicios y dependencias, una sola biblioteca puede aparecer en cientos de inventarios. Si el proveedor publica un estado VEX bien identificado, la plataforma puede separar antes los casos afectados de los que requieren investigación o cuentan con una justificación de no afectación.
Microsoft subraya que ampliar VEX no aumenta el número de actualizaciones de seguridad que un cliente debe desplegar. Muchas correcciones siguen llegando acumuladas o agrupadas. El objetivo es describir mejor la exposición y ayudar a priorizar, no multiplicar parches.
También conviene entender qué queda fuera:
- VEX no descubre todos los activos de una empresa ni corrige un inventario incompleto.
- No sustituye una SBOM, porque necesita una identidad de producto fiable con la que relacionarse.
- No reemplaza CVSS, EPSS, el catálogo KEV de CISA, la telemetría interna ni el análisis de exposición.
- No garantiza que la configuración real coincida con la condición evaluada por el proveedor.
- No decide por sí solo la ventana de mantenimiento, el riesgo de negocio o la urgencia operativa.
Cómo incorporar Microsoft VEX al flujo de vulnerabilidades
La forma más segura de adoptar datos VEX es tratarlos como una señal firmada y trazable dentro de un proceso más amplio. No hace falta automatizar el cierre de alertas desde el primer día. Un piloto en modo informativo permite medir cuántas coincidencias resuelve y dónde aparecen problemas de identidad de producto.
- Define el inventario que manda. Identifica equipos, servicios, aplicaciones, versiones, propietarios y criticidad. Sin esa base, ningún feed arreglará la falta de contexto.
- Conserva la SBOM y la procedencia. Registra quién generó el inventario de componentes, con qué herramienta, en qué fecha y para qué versión del producto.
- Consume la fuente oficial. Microsoft publica metadatos de proveedor CSAF que permiten localizar los documentos disponibles. Valida origen, integridad y fecha de actualización.
- Normaliza las identidades. Comprueba que producto, edición, versión y arquitectura coinciden. Evita aplicar por nombre una afirmación pensada para otra rama.
- Relaciona CVE, producto y estado. Guarda el estado VEX junto con la justificación, el documento de origen y la fecha de consulta.
- Combina señales de riesgo. Añade explotación conocida, exposición a Internet, privilegios, criticidad del activo y controles compensatorios.
- Empieza en modo revisión. Deja que la automatización sugiera prioridades o cierres, pero exige aprobación humana durante el piloto.
- Mide el resultado. Revisa reducción de falsos positivos, tiempo de triage, alertas reabiertas y casos mal correlacionados.
Para localizar la distribución oficial, Microsoft documenta su archivo provider-metadata de CSAF. Ese punto de entrada es preferible a recopilar avisos desde buscadores o páginas intermedias porque permite descubrir los recursos de forma estructurada y mantener la procedencia.
Cómo priorizar sin depender de una sola señal
Un buen flujo de vulnerabilidades no pregunta solo «¿aparece este CVE?». Pregunta qué activo está afectado, si puede alcanzarse el código vulnerable, qué privilegios exige, si existe explotación observada, qué impacto tendría una caída y qué control temporal reduce el riesgo.
Una matriz sencilla puede combinar estas capas:
| Señal | Pregunta útil | Ejemplo de decisión |
|---|---|---|
| VEX | ¿El proveedor declara el producto afectado, corregido o no afectado? | Separar casos confirmados de coincidencias sin impacto demostrado. |
| Inventario/SBOM | ¿La versión y el componente existen realmente en este activo? | Descartar coincidencias de software retirado o identificar propietarios. |
| Explotación | ¿Hay uso conocido en ataques o actividad interna sospechosa? | Elevar la urgencia frente a una vulnerabilidad solo teórica. |
| Exposición | ¿El servicio es accesible desde Internet o desde una zona sensible? | Priorizar el sistema alcanzable antes que un laboratorio aislado. |
| Impacto | ¿Qué ocurre si el activo se compromete o se detiene? | Ajustar la ventana y el nivel de validación del parche. |
Siete errores que conviene evitar al automatizar VEX
- Cerrar alertas solo por el texto «not affected»: hay que conservar producto, versión, justificación y condiciones.
- Ignorar «under investigation»: es un estado abierto que necesita seguimiento, no una ausencia de riesgo.
- Confundir componente con producto: una coincidencia de biblioteca no describe por sí sola la explotabilidad del producto final.
- Perder la procedencia: copiar el estado sin URL, fecha y emisor dificulta auditar una decisión meses después.
- Aplicar excepciones eternas: una nueva versión o revisión del documento puede cambiar el estado.
- Olvidar activos sin SBOM: el feed más completo no cubre sistemas que el inventario no conoce.
- Automatizar antes de medir: primero conviene comparar recomendaciones con decisiones humanas y registrar discrepancias.
Preguntas frecuentes sobre Microsoft VEX
¿VEX significa que ya no hace falta instalar los parches de Microsoft?
No. VEX aporta contexto sobre el estado de una vulnerabilidad respecto a un producto. Si el producto está afectado o existe una corrección aplicable, el proceso de actualización sigue siendo necesario.
¿VEX y SBOM son lo mismo?
No. Una SBOM describe componentes y dependencias de software. VEX comunica la valoración de explotabilidad de una vulnerabilidad para productos concretos. Juntos permiten pasar de «el componente aparece» a «el proveedor declara este estado para esta combinación».
¿Un estado «not affected» permite cerrar automáticamente una alerta?
No debería hacerse sin comprobar producto, versión, arquitectura, justificación y procedencia. En un piloto es más prudente marcarla para revisión y medir la calidad de la correlación.
¿Dónde publica Microsoft esta información?
Microsoft utiliza CSAF y ofrece metadatos de proveedor para descubrir sus documentos de seguridad y VEX de forma estructurada. El enlace oficial aparece en la sección de fuentes.
¿Qué diferencia hay entre VEX y el catálogo KEV de CISA?
VEX expresa el estado de una vulnerabilidad respecto a un producto. KEV identifica vulnerabilidades conocidas por haber sido explotadas. Son señales complementarias: una ayuda a precisar afectación y la otra aporta evidencia de explotación conocida.
Fuentes oficiales consultadas
- Microsoft Security Response Center: Expanding machine-readable VEX, publicado el 8 de septiembre de 2026.
- Microsoft Security Response Center: Introducing machine-readable VEX for Azure Linux and beyond.
- Microsoft CSAF provider metadata.
- CISA: SBOM Resources Library.
- OASIS: Common Security Advisory Framework 2.0.
Conclusión: menos ruido solo si se conserva el contexto
La ampliación de Microsoft VEX a todos sus CVE puede ahorrar tiempo en triage y hacer más coherente la automatización de vulnerabilidades. Su valor no está en cerrar más alertas por defecto, sino en aportar una afirmación estructurada del proveedor que pueda combinarse con inventario, SBOM, explotación conocida, exposición e impacto.
El mejor siguiente paso es pequeño: ingerir la fuente oficial, validar identidades de producto, conservar la procedencia y comparar durante unas semanas las recomendaciones automáticas con las decisiones del equipo. Si la correlación funciona, entonces puede ampliarse la automatización con una base más fiable.
Para reforzar ese proceso, también puedes revisar nuestra guía sobre cómo revisar alertas de certificados con menos ruido y el análisis de cómo priorizar una corrección crítica de WordPress. Ambos casos muestran la misma idea: la señal técnica resulta útil cuando se conecta con el activo y la acción correcta.