Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Una declaración del Vulnerability Exploitability eXchange (VEX) indica un estado concreto para una vulnerabilidad en uno o varios productos.
- Una declaración VEX es una afirmación de su autor, por lo que un auditor comprueba quién la ha emitido, si ha sufrido alguna modificación y qué análisis respalda su estado.
- La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) define cuatro estados VEX, y una declaración con el estado «no afectado» debe indicar el motivo, mediante un valor de justificación o una declaración escrita sobre el impacto.
- Hay varios formatos compatibles con VEX, y CycloneDX utiliza sus propias etiquetas de estado y justificación, por lo que puede ser necesario adaptar los nombres de sus documentos a los de la CISA.
- Cuando no existe una corrección en el código fuente, un proveedor puede indicar «no afectado» con una justificación, «afectado» con una declaración de medidas a tomar, o «corregido» una vez que la versión parcheada se haya incorporado a la compilación.
Una lista de materiales de software (SBOM) indica qué contiene una versión, pero no especifica cuáles de las vulnerabilidades que un escáner asocia a esos componentes afectan realmente a tu producto. VEX (Vulnerability Exploitability eXchange) cubre esa laguna: es la forma en que un proveedor o un tercero indica si una vulnerabilidad conocida afecta a un producto de software.
Las directrices VEX de la CISA consideran cada declaración como una afirmación de su autor. El grado de fiabilidad que el lector puede atribuir a una declaración depende de quién la haya emitido, cómo esté firmada y qué pruebas acepte el marco de cumplimiento del auditor. En este artículo, por «prueba de auditoría verificable» se entiende una afirmación que el auditor puede contrastar con el análisis en el que se basa. Una declaración VEX no constituye una prueba por sí misma.
¿Qué es el Intercambio de Vulnerabilidades y Exploitabilidad?
Tal y como lo describe la CISA, el VEX es una forma de indicar el estado de un producto o componente de software con respecto a una vulnerabilidad. Según los «Requisitos mínimos para el VEX» de la CISA, versión 1.0.0 de abril de 2023, un documento VEX es un contenedor de una o varias declaraciones. Cada declaración transmite un único estado para una única vulnerabilidad en uno o varios productos.
VEX está diseñado para integrarse con las listas de componentes de software (SBOM), las bases de datos de vulnerabilidades y los avisos de seguridad, pero la CISA afirma que no requiere ninguno de ellos. El documento de casos de uso de la CISA, de abril de 2022, describe un documento VEX como una forma de aviso de seguridad en sí mismo.
VEX es un formato de datos. No es una ley, y los requisitos mínimos de la CISA indican que no constituyen una política oficial de la CISA y que no imponen su cumplimiento. Los elementos mínimos de la SBOM para 2026 establecidos por la CISA y sus socios tampoco incluyen VEX.
Un proveedor o un tercero puede redactar un documento VEX. El autor debe identificarse como persona física u organización y es responsable del contenido.
Lo que VEX demuestra y lo que no demuestra a un auditor
Dado que el autor es responsable del contenido de un documento VEX, todo lo que figura en él constituye una afirmación de dicho autor. Las directrices de la CISA establecen que los documentos y las declaraciones deben estar firmados, y que la identidad del autor debe estar vinculada criptográficamente a la firma. Asimismo, exigen que se asigne una versión superior al documento cada vez que se modifique su contenido, además de incluir marcas de tiempo de la primera emisión y de la última actualización. Esto permite al auditor determinar quién realizó la afirmación, cuándo y si ha sufrido modificaciones desde entonces.
Según el documento de casos de uso de la CISA: La publicación de abril de 2022 indica que los estados de VEX no tienen por objeto poner fin a un debate. Su finalidad es ayudar a los consumidores a tomar decisiones informadas, de modo que el lector pueda cuestionar un estado en lugar de considerarlo definitivo.
La CISA y sus socios publicaron el 29 de julio de 2026 los «Elementos mínimos para una lista de materiales de software (SBOM) de 2026 ». Su sección «Correlación de la SBOM con los avisos de seguridad» aborda el VEX y el Marco Común de Avisos de Seguridad (CSAF). En ella se afirma que una actualización del estado ayuda a evitar esfuerzos innecesarios cuando una fuente fiable considera que un riesgo potencial no se traduce en un riesgo real. Esa ventaja depende de la confianza en la fuente, por lo que la identidad del emisor determina si un lector puede actuar en función de ese estado.
La combinación de VEX con una SBOM también requiere una SBOM completa. El elemento «Cobertura» del documento de 2026 establece que un destinatario debería poder concluir que una vulnerabilidad recién notificada no le afecta si la SBOM no incluye dicho componente, y esa conclusión solo es fiable si la SBOM incluye todos los componentes. El mismo documento sitúa la comprobación de la exactitud, la cobertura y la exhaustividad de una SBOM fuera de sus elementos mínimos, por lo que una declaración VEX que se base en una SBOM puede heredar cualquier error que contenga dicha SBOM.
Además, un informe VEX solo se refiere a las vulnerabilidades de un componente, por lo que no indica en absoluto si el paquete que has descargado ha sido manipulado o es malicioso. Si tu producto se basa en paquetes de código abierto, la fiabilidad de tus informes VEX dependerá exclusivamente de tu registro de los componentes que se han incluido en cada compilación.
Algunos revisores también solicitan el análisis en el que se basa cada hallazgo. En el caso de los productos sanitarios, la guía no vinculante sobre ciberseguridad previa a la comercialización de la Administración de Alimentos y Medicamentos de EE. UU. (FDA), de febrero de 2026, exige a los fabricantes una evaluación de los riesgos de seguridad y protección de cada vulnerabilidad conocida en sus componentes, además de los controles de riesgo que la abordan. Un estado sin análisis subyacente ofrece a dicho revisor poco que comprobar, por lo que los campos que recogen el razonamiento, que se tratan a continuación, son los más importantes.
Las cuatro situaciones y lo que debe explicar una declaración de no afectación
Los requisitos mínimos de la CISA, versión 1.0.0, establecen que cada declaración debe utilizar uno de los cuatro estados. Dos de ellos requieren un dato concreto, y en la tabla se indica cuáles.
| Estado | Lo que transmite al lector | Lo que también debe incluir la declaración | Fundamentos |
|---|---|---|---|
| No se ve afectado | No es necesario adoptar medidas correctoras ni de mitigación, ya que los productos mencionados no se ven afectados. | Un valor justificativo o una declaración por escrito en la que se explique por qué, en caso de que no exista justificación | Directrices de la CISA |
| Afectados | Los productos enumerados se ven afectados, y el autor recomienda tomar medidas | Una declaración de medidas, en la que se debe describir cómo subsanar o mitigar | Directrices de la CISA |
| Corregido | Los productos que figuran en la lista incluyen correcciones para la vulnerabilidad | Nada más allá de los campos que cada afirmación conlleva | Directrices de la CISA |
| En fase de investigación | El autor u otras personas están investigando el asunto y aún no han determinado su situación definitiva. | No hay nada más que añadir, aunque la CISA prevé que la situación cambie una vez que finalice la investigación. | Directrices de la CISA |
El documento de casos de uso de abril de 2022 exige una declaración de impacto para cada declaración de «no afectado». Los requisitos mínimos de abril de 2023 permiten sustituirla por una justificación.
Los requisitos mínimos establecen cinco valores de justificación, y el último es más estricto de lo que su nombre sugiere:
- El mensaje «Componente no presente» se aplica cuando el subcomponente vulnerable no está incluido en el producto.
- La expresión «el código vulnerable no está presente» se refiere a un componente que sí está presente, mientras que el código vulnerable no lo está, normalmente porque la configuración de compilación lo excluye.
- El código vulnerable que no se encuentra en la ruta de ejecución es aquel que no puede ejecutarse debido a la forma en que el producto lo utiliza.
- El «código vulnerable que no puede ser controlado por el adversario» se refiere al código que está presente y se utiliza, pero que un atacante no puede manipular para aprovechar la vulnerabilidad.
- Las medidas de mitigación integradas ya existentes requieren protecciones incorporadas que un atacante no pueda eludir, que un usuario no pueda configurar ni desactivar y que impidan por completo la explotación mediante vectores de ataque conocidos.
Cada valor suele requerir un tipo diferente de justificación: una SBOM u otro registro de composición, una configuración de compilación, un análisis de la ruta de llamada, un análisis del tratamiento de entradas o la propia medida de mitigación. Los requisitos de la CISA permiten que una declaración incluya notas sobre cómo se determinó su estado, así que anota esa justificación allí o junto a la declaración. El valor de la justificación por sí solo no explicará al revisor por qué has realizado esa afirmación.
Adapta el estado al trabajo que hayas realizado. «Afectado» indica a los lectores que el producto está expuesto y que el autor recomienda tomar medidas. No lo utilices para un hallazgo que aún no hayas analizado: mientras el análisis esté en curso, marca el hallazgo como «en investigación». La CISA espera que ese estado cambie cuando concluya la investigación, por lo que una declaración que lo mantenga sin actualizaciones indica al revisor que el análisis podría haberse estancado.
Formatos y especificaciones compatibles con VEX
Los requisitos mínimos de la CISA para 2023 mencionan tres formatos que pueden contener o utilizarse para generar documentos VEX: CSAF, CycloneDX y OpenVEX. Los requisitos definen sus elementos de datos independientemente de cualquier formato. El Software Package Data Exchange (SPDX), que no aparece mencionado en la lista de la CISA, también puede incluir los cuatro estados: su perfil de seguridad en la versión 3.0.1 cuenta con una clase de relación VEX para cada uno de ellos. La especificación VEX de cada formato define sus propios campos, y las versiones y el estado varían.
| Formato | Responsable del mantenimiento | Versión y estado, consultados el 19 de octubre de 2026 | Fundamentos |
|---|---|---|---|
| CSAF (perfil VEX) | Comité Técnico de la CSAF de OASIS | CSAF 2.0 se convirtió en un estándar de OASIS en noviembre de 2022 y se publicó como ISO/IEC 20153:2025. CSAF 2.1 se encuentra en la fase de «Borrador de especificación del comité 03», con fecha del 11 de septiembre de 2026. | Norma oficial (2.0), borrador (2.1) |
| CycloneDX | Fundación OWASP y Ecma TC54 | CycloneDX 1.7 se define en la norma ECMA-424, 2.ª edición, diciembre de 2025. | Norma formal |
| OpenVEX | Comunidad OpenVEX | Versión 0.2.0. El archivo README del proyecto sigue refiriéndose a la especificación como un borrador. | Especificaciones comunitarias |
| SPDX (Perfil de seguridad) | Proyecto SPDX | SPDX 3.0.1 es la última versión estable. La versión 3.1 se anunció como versión candidata en enero de 2026. | Especificaciones |
No todos los formatos utilizan las etiquetas de la CISA. La documentación del proyecto OpenVEX indica que CycloneDX VEX define sus propias etiquetas de estado y justificación, por lo que puede ser necesario traducir los documentos para que coincidan con los nombres de la CISA. En este artículo se utilizan en todo momento los nombres de la CISA. Elige el formato con el que ya trabajen tu cadena de herramientas y tus clientes, ya que los elementos de datos VEX no dependen de ello.
Cuando no existe una solución en la fase anterior
Lo que hay que demostrar depende de si existe una corrección. Si el desarrollador original ha publicado una y tú la distribuyes, la declaración puede indicar «corregido» y mencionar las versiones del producto que la contienen. Una declaración de «solucionado» no suele requerir un análisis de si el código vulnerable puede ejecutarse, ya que apunta a una solución. Su respaldo suele ser el artefacto parcheado y un registro de versiones. La declaración sigue siendo una afirmación del emisor, por lo que las versiones exactas son importantes. El documento de casos de uso de la CISA recomienda indicar las versiones de forma explícita siempre que sea posible, ya que los rangos de versiones complejos son más difíciles de interpretar.
Sin una solución, tienes tres opciones. Puedes analizar el hallazgo y publicar que no está afectado con una justificación, publicar que está afectado con una declaración de medidas a tomar, o incorporar una versión parcheada a tu compilación y publicar que está solucionado. La primera opción implica un análisis que queda obsoleto a medida que cambia el código. El documento de casos de uso de la CISA advierte de que una declaración sobre todas las versiones también abarca las futuras y puede incluir versiones que ya se encuentran al final de su ciclo de vida. Su ejemplo es la afirmación de que un programa en Rust no puede verse afectado por una vulnerabilidad de Java, lo cual resulta engañoso si una versión posterior adopta Java y nadie actualiza el documento. La segunda opción tiene su propia limitación. Si el análisis muestra que tu producto está expuesto, la declaración de medidas no puede indicar a los lectores que actualicen a una versión corregida que aún no existe. Debe describir una medida de mitigación u otra acción que los lectores puedan llevar a cabo.
La tercera vía es la que se complica debido a los componentes que no reciben mantenimiento. Es posible que nadie en la cadena de desarrollo esté trabajando en la corrección que necesitarías, por lo que alguien tiene que aplicar un parche a la versión que utilizas y, a continuación, confirmar que sigue comportándose tal y como espera tu producto. La alternativa a aplicar un parche es sustituir el componente, lo que normalmente implica tener que modificar el código en todos los lugares donde se utilice.
Un orden que funciona cuando eres tú quien hace las declaraciones:
- Asegúrate de que la SBOM coincida con lo que se envía. Si incluye un componente por error, corrige la SBOM en lugar de emitir una declaración de «no afectado» para ese componente.
- Aplica las correcciones disponibles y, a continuación, emite comunicados de corrección en los que se indiquen las versiones que las contienen.
- En el caso de los componentes para los que no exista una solución, decide entre incluir una versión parcheada en tu compilación, comprobar si hay una declaración de «no afectado» o emitir una declaración de «afectado» con una acción correspondiente.
- Marca como «en investigación» todo aquello cuyo análisis aún esté en curso y actualiza la declaración cuando se haya completado el trabajo. Cualquier cambio aumenta la versión del documento.
Cada paso deja un registro que un auditor puede comprobar: la SBOM corregida, las versiones actualizadas, el análisis en las notas de estado y el historial de versiones del documento.
Controlar lo que se incluye en la compilación
Dado que el estado VEX no permite saber si un paquete ha sido manipulado o si coincide con el código fuente publicado por su proyecto, la integridad de la compilación requiere un control específico.
SecureChain, de TuxCare, analiza el código fuente de cada paquete en busca de malware y patrones de código sospechosos, bloquea cualquier paquete que no supere la comprobación y recompila el resto a partir del código fuente en entornos aislados y reforzados. Mientras el desarrollador original siga publicando correcciones, aplica los parches a cada paquete conforme a un acuerdo de nivel de servicio (SLA) contractual. Todos los paquetes se entregan con procedencia de nivel 3 según el estándar SLSA (Supply-chain Levels for Software Artifacts), listas de materiales de software (SBOM) y declaraciones VEX. En cuanto a la tercera opción mencionada anteriormente, cuando el desarrollador original deja de corregir un componente, SecureChain pasa automáticamente el relevo al servicio Endless Lifecycle Support (ELS), que sigue proporcionando correcciones una vez finalizado el mantenimiento por parte del desarrollador original. La cobertura abarca los ecosistemas de JavaScript, Python, Java, Go y PHP.
Si no sabes qué se ha incluido en una compilación, o si tus análisis se atascan continuamente porque los paquetes de origen han dejado de recibir correcciones, pregunta a nuestro equipo cómo lo gestiona SecureChain.
PREGUNTAS FRECUENTES
¿Es obligatorio por ley utilizar VEX?
El formato Vulnerability Exploitability eXchange (VEX) no es una ley. La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) afirma que sus requisitos mínimos para el formato VEX no constituyen una política oficial y no obligan a su cumplimiento, y que en los elementos mínimos de la lista de materiales de software (SBOM) para 2026 no se incluye el VEX como campo obligatorio. No obstante, un contrato con un cliente sí puede exigirlo.
¿Quién puede redactar una declaración VEX?
Según la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA), una declaración del Vulnerability Exploitability eXchange (VEX) puede proceder del proveedor del software o de un tercero. El autor debe identificarse como persona física u organización y es responsable del contenido. El autor también puede indicar una función, como por ejemplo «proveedor».
¿Qué contiene un archivo VEX?
Un archivo del Vulnerability Exploitability eXchange (VEX), al que la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) denomina «documento VEX», contiene metadatos del documento y al menos una declaración. Cada declaración indica un estado para una vulnerabilidad en uno o varios productos, además de cualquier detalle que requiera dicho estado, como una declaración de acción o una justificación.
¿Qué significa que una vulnerabilidad no tenga estado VEX?
No se puede sacar ninguna conclusión al respecto. La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) afirma que el Vulnerability Exploitability eXchange (VEX) no implica ningún estado por defecto más allá de lo que indique explícitamente una declaración, y que un documento puede estar incompleto. Una vulnerabilidad sin declaración no se ha declarado como no afectada.
¿Es necesario firmar un documento VEX?
La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) afirma que los documentos y declaraciones de Vulnerability Exploitability eXchange (VEX) deben firmarse, por lo que la firma se considera una recomendación. La identidad del autor debe estar vinculada a la firma, y la firma de un documento debe abarcar todos sus metadatos y declaraciones. Las implementaciones deben ser compatibles con los mecanismos de firma comúnmente aceptados.
¿Se puede utilizar VEX sin una SBOM?
Sí. La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) afirma que Vulnerability Exploitability eXchange (VEX) está diseñado para integrarse con una lista de materiales de software (SBOM), bases de datos de vulnerabilidades y avisos de seguridad, pero no requiere ninguno de ellos. Cuando existe una SBOM, los identificadores de producto de VEX deben hacer referencia a los identificadores que ya figuran en ella.
