VEX: lo que dice un documento Vulnerability Exploitability eXchange

¿Qué es VEX?

VEX, abreviatura de Vulnerability Exploitability eXchange, es una declaración legible por máquina sobre si un producto está afectado por una vulnerabilidad conocida concreta. Un proveedor la publica para que quienes utilizan el producto sepan qué vulnerabilidades requieren alguna acción y cuáles no. En la mayoría de las organizaciones, ese trabajo del proveedor recae en el equipo de respuesta a incidentes de seguridad de productos (PSIRT).

Los Minimum Requirements for VEX de CISA (abril de 2023) lo definen con independencia de cualquier formato de archivo: un documento VEX es un contenedor de una o más declaraciones VEX, y cada declaración da un estado para una vulnerabilidad en uno o más productos. VEX está pensado para funcionar con SBOM, bases de datos de vulnerabilidades y avisos de seguridad, pero no necesita ninguno de ellos.

Por qué existe VEX: el ruido de las SBOM

Una SBOM enumera todos los componentes de un producto, incluidas las dependencias transitivas. Un escáner coteja esos componentes con los avisos e indica cada CVE de cada versión que encuentra. Muchos de esos hallazgos no son aplicables: la función vulnerable nunca se invoca, una opción de build la excluye de la compilación o la configuración del producto bloquea el ataque. Sin VEX, cada cliente tiene que averiguarlo por su cuenta o abrir un ticket de soporte para preguntar al proveedor.

VEX traslada ese análisis a quien puede hacerlo una sola vez para todos: el proveedor. El escáner del cliente lee el documento VEX y suprime los hallazgos que el proveedor ha marcado como no aplicables al producto.

Los cuatro estados de VEX

Cada declaración VEX lleva exactamente uno de cuatro estados:

Estado	Significado	También se exige
not_affected	No se requiere corrección ni mitigación. La vulnerabilidad no afecta a los productos enumerados.	Una justificación o una declaración de impacto que explique por qué
affected	La vulnerabilidad afecta a los productos enumerados, y el autor recomienda actuar.	Una declaración de acción: qué deben hacer los usuarios
fixed	Las versiones de producto enumeradas contienen una corrección.	Nada más
under_investigation	El autor lo está investigando y aún no ha decidido.	Nada más; se espera que cambie

Justificaciones de VEX para not_affected

Una declaración not_affected tiene que decir por qué. Los requisitos de CISA indican que DEBERÍA usar una de cinco justificaciones y que, si no lo hace, DEBE incluir una declaración de impacto en texto libre. OpenVEX y CSAF utilizan las mismas cinco:

• component_not_present: el componente vulnerable no está incluido en el producto.
• vulnerable_code_not_present: el componente está incluido, pero el código vulnerable no, normalmente por cómo se configuró o se compiló.
• vulnerable_code_not_in_execute_path: el código vulnerable está presente, pero el producto nunca lo invoca.
• vulnerable_code_cannot_be_controlled_by_adversary: el código está presente y se utiliza, pero un atacante no puede controlarlo para explotar la vulnerabilidad.
• inline_mitigations_already_exist: unas protecciones integradas que los usuarios no pueden desactivar impiden la explotación.

Las justificaciones difieren en las evidencias que necesitan. component_not_present necesita un registro preciso de lo que contiene el producto. Las tres intermedias necesitan análisis de código, como análisis de alcanzabilidad o una revisión manual, y son las que los clientes cuestionan con más frecuencia.

Qué contiene una declaración VEX

Los requisitos mínimos de CISA enumeran estos elementos:

• Metadatos del documento: un identificador de documento, una versión que aumenta con cada cambio, el autor (una persona u organización, no una herramienta) y cuándo se emitió por primera vez y cuándo se actualizó por última vez.
• Detalles del producto: uno o más identificadores de producto, idealmente los mismos que utiliza la SBOM del producto, como una package URL (purl). Una declaración también puede nombrar el subcomponente que contiene la vulnerabilidad.
• Detalles de la vulnerabilidad: un identificador de vulnerabilidad por declaración, normalmente una CVE, y una descripción o un enlace a ella.
• Estado, con la justificación, la declaración de impacto o la declaración de acción que exija.
• Metadatos de la declaración: un identificador, una versión y marcas de tiempo de la propia declaración.

Un ejemplo de documento VEX

Este documento OpenVEX indica que un producto, example-api 3.2.0, distribuye una versión vulnerable de log4j-core pero no está afectado por Log4Shell, porque la clase vulnerable se elimina durante el build:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

El producto y su subcomponente se identifican con package URL, de modo que un escáner puede cotejarlos con los componentes de la SBOM del producto. La misma declaración en CycloneDX o CSAF contiene los mismos datos con otra estructura.

Formatos de VEX: OpenVEX, CycloneDX VEX y CSAF VEX

VEX es un conjunto de requisitos, no un formato de archivo. CISA nombra tres formatos que pueden contenerlo, y no son intercambiables:

	OpenVEX	CycloneDX VEX	CSAF VEX
Qué es	Un pequeño formato JSON creado solo para VEX	La sección vulnerabilities de un documento CycloneDX	El perfil csaf_vex del estándar de avisos CSAF
Estándar	Especificación abierta, v0.2.0	ECMA-424 (CycloneDX 1.6 y posteriores)	OASIS Standard (CSAF 2.0, 2022)
Estados	Los cuatro estados de VEX	Sus propios estados de análisis: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	Listas de estado de producto: known_not_affected, known_affected, fixed, under_investigation
Justificaciones	Las cinco justificaciones de CISA	Nueve propias, como code_not_reachable y requires_configuration	Las cinco justificaciones de CISA, como flags
Adecuado para equipos que	Quieren el archivo VEX más pequeño posible	Ya distribuyen SBOM CycloneDX	Ya publican avisos de seguridad CSAF
Lo lee Trivy	Sí	Sí, en escaneos de SBOM	Sí
Lo lee Grype	Sí	No indicado	Sí

OpenVEX es el más ligero: un documento con un autor, una marca de tiempo, una versión y una lista de declaraciones. Su especificación trata VEX como una secuencia de declaraciones, cada una de las cuales anula o amplía las anteriores.

CycloneDX VEX utiliza la misma estructura vulnerabilities que CycloneDX usa para todo lo demás, con un objeto analysis que contiene un estado, una justificación, valores de respuesta como update o will_not_fix y detalles en texto libre. Los datos VEX pueden estar dentro de la SBOM o en un documento CycloneDX aparte que apunte a la SBOM con BOM-Link. Tenga en cuenta que su vocabulario de justificaciones no es el de CISA, de modo que convertir desde o hacia OpenVEX o CSAF requiere una correspondencia. Consulte CycloneDX vs SPDX para el lado de la SBOM.

CSAF VEX es un documento CSAF completo con la categoría csaf_vex. Exige un árbol de productos, una CVE u otro identificador, notas y, para cada producto, una declaración de impacto (si no está afectado) o una corrección (si lo está). Es más pesado que OpenVEX, pero encaja en organizaciones que ya distribuyen avisos CSAF a través de un proveedor de CSAF.

VEX vs VDR

Un Vulnerability Disclosure Report (VDR) enumera las vulnerabilidades que sí afectan a un producto, junto con su análisis y su corrección. NIST SP 800-161 recomienda los VDR como práctica de cadena de suministro, y CycloneDX admite ambos. La diferencia, según los ejemplos de CycloneDX:

• VDR indica qué vulnerabilidades afectan al producto. Puede cubrir vulnerabilidades encontradas en su propio código que nunca se publicaron en otro lugar.
• VEX es principalmente una declaración negativa: qué vulnerabilidades conocidas no afectan al producto y por qué. Solo cubre vulnerabilidades conocidas.

Muchos proveedores publican ambos: el VDR responde a «qué tengo que corregir» y el VEX a «qué puedo ignorar».

Cómo consumen VEX los escáneres

Un documento VEX solo ahorra trabajo si las herramientas del cliente lo leen. Dos escáneres de código abierto muy utilizados lo hacen:

• Trivy recibe VEX mediante su opción --vex (marcada como experimental) desde un archivo local, un repositorio VEX, una atestación OCI o una referencia en la SBOM. Lee OpenVEX, CycloneDX VEX en escaneos de SBOM y CSAF VEX, y deja de indicar las vulnerabilidades marcadas como not_affected.
• Grype recibe OpenVEX y CSAF VEX mediante --vex. Traslada las coincidencias not_affected y fixed a una lista de ignorados, que se muestra con --show-suppressed, y opcionalmente puede añadir a los resultados las declaraciones affected y under_investigation.

La coincidencia depende de los identificadores. Si el VEX nombra el producto con un identificador distinto al de la SBOM, el escáner no puede relacionarlos y el hallazgo se mantiene.

Quién publica VEX

VEX suele proceder del proveedor: el fabricante de software, la distribución de código abierto o el fabricante del dispositivo que distribuye el producto. Dentro del proveedor, es una tarea del PSIRT, parte del mismo ciclo de vida de la gestión de vulnerabilidades que produce los avisos y las correcciones. Red Hat, por ejemplo, publica documentos CSAF VEX en un directorio específico de su feed de CSAF, junto a sus avisos. Para saber qué hacen a diario los ingenieros de PSIRT, consulte la función de PSIRT.

Los clientes también escriben VEX para uso propio, registrando decisiones de triaje sobre el producto de un proveedor para que su escáner deje de señalarlas. Normativas como el Cyber Resilience Act de la UE piden a los fabricantes gestionar las vulnerabilidades de los componentes que distribuyen, y VEX es una forma de indicar a los usuarios cuáles son aplicables.

Mantener VEX actualizado

• Los estados cambian. Una declaración suele empezar como under_investigation y terminar como not_affected, o como affected y después fixed. Publique cada cambio; CISA exige que la versión aumente cada vez.
• Las versiones nuevas necesitan declaraciones nuevas. Un veredicto not_affected para 3.2.0 no dice nada de 3.3.0. Vuelva a comprobarlo cuando cambien el componente, su versión o la configuración del build.
• Mantenga VEX separado de la SBOM. La SBOM describe una versión y permanece fija. VEX sigue cambiando después del lanzamiento, de modo que publicarlo como documento propio evita tener que volver a emitir las SBOM.
• Publíquelo donde miran las herramientas. Junto a la SBOM, como atestación en la imagen de contenedor o en su feed de avisos, e indique dónde en su política de divulgación. Consulte divulgación coordinada de vulnerabilidades.

Límites de VEX

• Es una afirmación, no una prueba. Una declaración not_affected es la valoración de su autor. CISA recomienda vincular criptográficamente la identidad del autor al documento, pero la mayoría de los consumidores siguen confiando en VEX porque confían en el proveedor.
• El silencio no significa nada. VEX no implica ningún estado predeterminado. Una vulnerabilidad sin declaración es desconocida, no «no afectada».
• Los formatos no se corresponden uno a uno. CycloneDX utiliza estados y justificaciones distintos de los de OpenVEX y CSAF, de modo que las conversiones pierden detalle.
• Solo es tan bueno como el inventario. Decir que un componente no está presente exige saber exactamente qué contiene el producto, incluidas las dependencias transitivas y todo lo que el build descargó fuera del gestor de paquetes.

VEX empieza con una SBOM precisa

Toda declaración VEX apunta a componentes, y la justificación más fácil de defender, component_not_present, solo es cierta si el inventario está completo. Una SBOM generada escaneando lockfiles a posteriori puede enumerar dependencias de desarrollo que nunca se distribuyen y pasar por alto paquetes que el build descargó de otra forma.

CRACI ejecuta builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés y las dependencias que ningún lockfile enumera. Cada SBOM lleva un estado de completitud y se exporta como CycloneDX o SPDX. Las SBOM monitorizadas se reevalúan de forma continua, el historial de builds muestra qué builds anteriores contenían una dependencia vulnerable, y CRACI es compatible con VEX. Consulte la generación de SBOM y el seguimiento de vulnerabilidades.

VEX: preguntas frecuentes

¿Qué significa VEX?

VEX significa Vulnerability Exploitability eXchange. Es una declaración legible por máquina de si un producto está afectado por una vulnerabilidad conocida concreta, publicada para que los usuarios sepan qué vulnerabilidades notificadas requieren alguna acción.

¿Cuál es la diferencia entre una SBOM y VEX?

Una SBOM enumera los componentes de un producto. VEX indica, para una vulnerabilidad dada, si ese producto está afectado. La SBOM rara vez cambia después de un lanzamiento; las declaraciones VEX cambian a medida que el proveedor investiga y corrige. Por eso VEX suele publicarse como un documento aparte que hace referencia al producto, en lugar de integrarse en la SBOM.

¿Cuáles son los cuatro estados de VEX?

not_affected, affected, fixed y under_investigation. Una declaración not_affected necesita una justificación o una declaración de impacto, y una declaración affected necesita una declaración de acción que indique qué deben hacer los usuarios.

¿Qué formato de VEX debo utilizar?

Utilice el que lean sus consumidores y sus herramientas. OpenVEX es el más pequeño y funciona con Trivy y Grype. CycloneDX VEX se adapta a los equipos que ya distribuyen SBOM CycloneDX. CSAF VEX se adapta a las organizaciones que ya publican avisos de seguridad CSAF, algo habitual en el software industrial y empresarial. Muchos proveedores acaban convirtiendo entre ellos.

¿VEX es lo mismo que un aviso de seguridad?

No. Un aviso de seguridad explica una vulnerabilidad, a quién afecta y cómo corregirla, principalmente para personas. VEX es un estado concreto y legible por máquina por producto y vulnerabilidad, principalmente para herramientas. Ambos suelen ir juntos: el estándar CSAF tiene un perfil de aviso de seguridad y un perfil VEX.

¿Quién escribe los documentos VEX?

Normalmente el proveedor del producto, a menudo su equipo de respuesta a incidentes de seguridad de productos (PSIRT), porque sabe cómo se compila y se configura el producto. Los requisitos mínimos de CISA también permiten que terceros sean autores de VEX, y cada documento debe nombrar a su autor.

¿Los escáneres de vulnerabilidades leen VEX?

Varios sí. Trivy acepta OpenVEX, CycloneDX y CSAF VEX mediante su opción --vex y descarta los hallazgos marcados como not_affected. Grype acepta OpenVEX y CSAF VEX mediante --vex y traslada los hallazgos not_affected y fixed a una lista de ignorados.