Blog HackRTU

‹ Regresar

EL TÉRMINO VEX Y SU APLICABILIDAD CON LOS SBOM

 

cna

 

 

El término VEX o Vulnerability Exploitability eXchange, hace referencia a un formato estandarizado el cual se utiliza para la transmisión de información sobre la posibilidad de explotar una vulnerabilidad de un producto concreto, ya sea software o hardware.

A grandes rasgos, aunque a lo largo del artículo lo veremos en detalle, permite priorizar diferentes acciones como la aplicación de parches, mitigaciones o incluso programar ventanas de mantenimiento de forma más efectiva.

La detección de una vulnerabilidad (CVE) se ve complementada con la información proporcionada por el VEX, ya que el Vulnerability Exploitability eXchange se centra en si la vulnerabilidad en un componente puede realmente explotarse en un contexto específico, es decir, para un modelo y versión exacta.

A diferencia del EPSS, el cual predice la probabilidad de que un CVE sea explotado en los próximos días, el VEX, proporciona un formato estandarizado para declarar si un CVE es explotable o no en un producto concreto y el por qué. El objetivo principal del VEX es complementar al SBOM (Software Bill of Materials) y como se ha mencionado antes, ayudar en la priorización de acciones, aunque VEX puede ser también independiente de SBOM.

 

VULNERABILITY EXPLOITABILITY EXCHANGE

El VEX, surgió con el objetivo de permitir que un proveedor de software o hardware declaren el estado de vulnerabilidades específicas en un producto determina.

En el año 2021, concretamente el 27 de septiembre, la Administración Nacional de Telecomunicaciones e Información (NTIA) de EE.UU, publica un documento técnico divulgativo sobre el término VEX y su uso con CSAF (Common Security Advisory Framework) como estándar OASIS. VEX, se ha materializado como perfil dentro de CSAF, el cual es un estándar para la creación y compartición de avisos de seguridad de forma estructurada, normalmente sobre vulnerabilidades.

En el año 2022, la CISA (Cybersecurity and Infrastructure Security Agency) comenzó a promover el uso de VEX y aparecen las primeras herramientas open source para su implementación y uso. Actualmente, VEX se ha integrado en herramientas referentes del mercado.

En definitiva, VEX posibilita las siguientes características:

• Permitir que un proveedor de software u otras partes declaren el estado de vulnerabilidades específicas en un componente de un producto determinado.
• Un método de publicación de avisos de seguridad, similar a los publicados por CNAs o PSIRTs pero con mejoras significativas:
  • Integración con herramientas de seguridad y plataformas de seguimiento de vulnerabilidades gracias a que los documentos VEX son machine readable, es decir, VEX sigue una estructura estándar para organizar la información y las herramientas pueden entender todos los campos sin gran dificultad.
  • Los datos VEX ayudan a complementar y enriquecer el uso de SBOM.
• Permite aumentar la automatización en todo el ciclo de una vulnerabilidad a nivel de divulgación, seguimiento y posibles mitigaciones.

 

LOS POSIBLES ESTADOS DE ACCIÓN EN REFERENCIA AL VEX

Como VEX es un indicativo del estado de una vulnerabilidad para un componente o un producto específico, de ahí su relación con los SBOM, permite catalogar en varios estados dichos componentes o productos específicos.

• Not affected (No afectado): No se requiere ninguna acción de remediación.
• Affected (Afectado): Se recomiendan acciones para mitigar o corregir la vulnerabilidad.
• Fixed (Corregido): Las versiones del producto mencionadas ya contienen la corrección.
• Under Investigation (En investigación): Aún no se sabe si las versiones están afectadas; se proporcionará una actualización en una versión posterior.

La combinación entre un SBOM y el estado de las vulnerabilidades de los VEX proporciona a una visión potente y actualizada del estado de seguridad de los productos.

 

OPENVEX, IMPLEMENTACIÓN ABIERTA Y SIMPLIFICADA DEL VEX

Dentro de la estandarización de VEX, existe implementaciones abiertas y simplificadas como OpenVEX (Open Vulnerability Exploitability eXchange), actualmente en su especificación v.0.2.0 y que sigue los requisitos mínimos para VEX establecidos en coordinación entre el VEX Working Group y la CISA.

A continuación, se presenta un ejemplo para la vulnerabilidad CVE-2025-64386 descubierta por nuestros investigadores a principios de 2025.

• CVE: CVE-2025-64386
• Descripción: El equipo concede un token JWT para cada conexión en la línea de tiempo, pero durante una sesión válida activa, se puede realizar un secuestro del token. Esto permitirá a un atacante con el token modificar los parámetros de seguridad, acceder o incluso robar la sesión sin que la sesión legítima y activa lo detecte. El servidor web permite al atacante reutilizar un token JWT de sesión antiguo mientras la sesión legítima está activa.
• CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
• Score: 7.7
• CWE: CWE-613 Insufficient Session Expiration

Ahora, con una visión básica sobre la vulnerabilidad (más información sobre el CVE), se procede a mostrar el JSON-LD con los campos mínimos correspondientes:

{   "@context": "https://openvex.dev/context/v1",   "schema_version": "0.2.0",   "author": {     "name": "HackRTU",     "role": "Industrial Security Company"   },   "timestamp": "2025-11-05T09:00:00Z",   "document_id": "https://www.hackrtu.com/blog/cg-0day-003/",   "statements": [     {       "vulnerability": {"id": "CVE-2025-64386"},       "products": [         {           "purl": "pkg:circutor/tcprs1plus@1.0.14",           "type": "firmware",           "cpe": "cpe:2.3:a:circutor:tcprs1plus:1.0.14:*:*:*:*:*:*:*"         }       ],       "status": "affected"     }   ] }

 

El JSON Schema global se puede encontrar en su repositorio oficial. En el indican todos los campos que se pueden definir dentro de la implementación OpenVEX de VEX.

Desde HackRTU, vemos el estándar VEX como un posible acompañamiento para los SBOM, una forma de simplificar el proceso y ayudar a proveedores a proporcionar más información sobre la posibilidad de que una vulnerabilidad en un activo, software o componente del SBOM sea explotada. Así mismo, existen otros términos, estándares y conceptos como el EPSS que pueden ayudar a determinar la posibilidad de que una vulnerabilidad sea explotada pero no proporcionan un listado en un lenguaje y formato automatizable para ser integrado en las herramientas de seguridad relacionadas con la gestión de las vulnerabilidades.

 

 

EQUIPO DE HACKRTU