VEX: filtrar ruido de vulnerabilidades con contexto

Actualizado: 2026-05-03

Quien haya pasado por la pesadilla de Log4Shell en diciembre de 2021 entiende por qué VEX existe. En aquellos días, cualquier aplicación Java tenía un CVE crítico asociado, y muchísimas de ellas no eran en absoluto vulnerables: no exponían la clase afectada, no procesaban entradas externas con la librería, o simplemente no se cargaba la pieza vulnerable en runtime. Pero sin una manera estructurada de comunicarlo, cada proveedor respondía preguntas una y otra vez, y cada cliente reevaluaba el mismo riesgo desde cero. Tres años después, el sector ha recogido esa lección y el Vulnerability Exploitability eXchange (VEX) está tomando cuerpo como mecanismo estándar para filtrar ese ruido.

Este post explica qué es VEX, cuándo añade valor en un pipeline de supply chain, qué formatos existen, y qué errores se repiten en las adopciones que he visto. Para el contexto más amplio de gestión de supply chain de software, el artículo sobre Sigstore y adopción en registries ofrece la capa de integridad que complementa a VEX.

Puntos clave

• VEX es un documento estructurado que comunica la explotabilidad real de un CVE en el contexto de un producto específico.
• Los estados VEX son cuatro: not affected, affected, fixed, under investigation.
• Los formatos principales son CycloneDX (VEX embebido en SBOM), CSAF VEX y OpenVEX (más ligero).
• VEX no sustituye al SBOM; lo complementa añadiendo el contexto de impacto que el SBOM no tiene.
• El error más común es emitir VEX sin evidencia: «not affected» sin justificación no vale nada para quien lo recibe.

Qué es VEX y qué problema resuelve

Un SBOM lista los componentes de un artefacto de software. Cuando una base de datos de vulnerabilidades (NVD, GHSA) reporta un CVE en uno de esos componentes, el escáner de dependencias lo marca como vulnerable. El problema es que ese flag no distingue entre «el componente está incluido y la vulnerabilidad es explotable en este contexto» y «el componente está incluido pero el código vulnerable no se ejecuta nunca, o el vector de ataque no aplica a cómo lo usamos».

VEX es el mecanismo que permite comunicar esa distinción. Un documento VEX, emitido por el proveedor del producto, afirma explícitamente el estado de explotabilidad de un CVE específico en ese producto específico. El receptor (el cliente, el escáner, la plataforma de gestión de vulnerabilidades) puede usar esa información para suprimir alertas de falso positivo o para priorizar remediación de manera más precisa.

La analogía útil es la de un atestado: no elimina el CVE de la base de datos, pero acredita que para este producto, en este contexto, el CVE no es explotable de la forma que describe la descripción genérica.

Los cuatro estados VEX

La especificación VEX define cuatro estados posibles para un componente en relación a un CVE:

• Not affected: el producto incluye el componente pero no es vulnerable. Requiere justificación (las categorías estándar son: component not present, vulnerable code not present, inline mitigations already exist, vulnerable code cannot be controlled by adversary).
• Affected: el producto es vulnerable al CVE. Puede incluir información adicional sobre el vector de ataque o las condiciones de explotabilidad.
• Fixed: el CVE ha sido remediado en la versión especificada del producto.
• Under investigation: el proveedor está evaluando el impacto del CVE; estado transitorio que indica que la respuesta está en curso.

La categoría de justificación para «not affected» es la parte más importante en la práctica. Un «not affected» sin justificación no aporta más confianza que la ausencia de información, porque el receptor no puede saber si el proveedor realmente analizó el impacto o simplemente marcó sin investigar.

Formatos: CycloneDX, CSAF y OpenVEX

Hay tres formatos principales para emitir VEX:

CycloneDX con VEX embebido. CycloneDX es un formato de SBOM que incluye soporte nativo para VEX como parte del mismo documento o como documento de vulnerabilidad separado (BOM-Link). Es el más integrado con el ecosistema de herramientas que ya generan SBOMs en CycloneDX (Syft, Trivy, CDXGEN). Si ya tienes un pipeline de SBOM en CycloneDX, es el camino de menor fricción.

CSAF VEX. CSAF (Common Security Advisory Framework) es el estándar de OASIS para avisos de seguridad, y su perfil VEX es el más adecuado para organizaciones con procesos formales de divulgación de vulnerabilidades. Es el formato preferido por grandes fabricantes de software empresarial y el que mejor se integra con las plataformas de gestión de vulnerabilidades de proveedores. Tiene más estructura y overhead que los otros dos.

OpenVEX. Formato más ligero, impulsado por Chainguard y adoptado por el proyecto SLSA. Está en JSON-LD y es el más fácil de generar y consumir programáticamente. No tiene el ecosistema de herramientas de los otros dos todavía, pero es el que más compatibilidad tiene con la cadena de integridad de software moderna (Sigstore, cosign, SLSA).

Cómo encaja en un pipeline de supply chain

VEX se integra mejor cuando hay un flujo de generación de SBOM ya establecido. El pipeline típico con VEX tiene tres fases:

1. Generación del SBOM: en el proceso de build, usando Syft, Trivy o la herramienta específica del lenguaje. El SBOM describe los componentes exactos del artefacto.
2. Escaneo de vulnerabilidades: el SBOM se pasa a un escáner (Grype, Trivy, Dependency-Track) que cruza los componentes con bases de datos de vulnerabilidades y produce una lista de CVEs.
3. Aplicación del VEX: el escáner o la plataforma de gestión aplica los documentos VEX disponibles para suprimir falsos positivos o actualizar el estado de vulnerabilidades ya remediadas.

El paso que más falta es el proceso interno de generación del VEX: quién determina el estado de cada CVE, cómo se documenta la justificación, con qué cadencia se revisa. Sin ese proceso interno, el VEX no se genera o se genera sin rigor.

Errores comunes en la adopción

Los errores que he visto repetirse en organizaciones que empiezan con VEX:

Emitir VEX sin evidencia. «Not affected» sin justificación categorizada y sin evidencia de que alguien realmente analizó el impacto es peor que no emitir nada, porque da una falsa sensación de seguridad. La justificación no tiene que ser elaborada, pero sí tiene que existir y ser específica.

Tratar VEX como una solución al ruido en vez de como una disciplina. VEX reduce el ruido de falsos positivos a largo plazo, pero requiere inversión inicial: analizar cada CVE relevante, categorizar, documentar. Organizaciones que esperan que VEX resuelva el problema de gestión de vulnerabilidades sin esa inversión se decepcionan.

No tener un proceso de actualización. Un VEX emitido con «not affected» puede quedar obsoleto si cambia el uso del componente en el producto o si se descubre un vector de ataque no considerado. Sin revisión periódica, el VEX acumulado es una deuda de confianza.

Confundir la generación automática de VEX con VEX de calidad. Algunas herramientas generan VEX automáticamente inferiendo el estado a partir del análisis estático. Puede ser un buen punto de partida, pero el VEX generado automáticamente sin revisión humana tiene la misma fiabilidad que el análisis que lo produce, que a menudo tiene falsos positivos y falsos negativos.

Mi lectura

VEX es la pieza que faltaba entre el SBOM y la decisión de remediación. El SBOM dice qué hay; VEX dice qué importa en este contexto. Sin VEX, cada CVE en el SBOM exige investigación. Con VEX bien emitido, la investigación ya está hecha y documentada por quien mejor la puede hacer: el proveedor del componente o del producto.

La adopción en pipelines de CI/CD va avanzando, pero el cuello de botella es el proceso humano de análisis y justificación. Los equipos que lo resuelven mejor son los que tratan VEX como parte del proceso de gestión de vulnerabilidades, no como un artefacto que se genera automáticamente al final del build. La calidad del VEX es la calidad del análisis que lo respalda.