VEX en CycloneDX, OpenVEX y CSAF

OpenVEX es una especificación pequeña, en JSON, hecha solo para VEX; su versión 0.2.0 usa los cuatro estados con los nombres ya vistos. CycloneDX es un formato de SBOM que puede llevar vulnerabilidades y, dentro de cada una, un bloque analysis con estado, justificación y respuesta; sus estados tienen otros nombres. CSAF es un estándar de avisos de seguridad (OASIS) con un perfil llamado VEX; allí el estado vive en product_status y se nombra con prefijos como known_.

La tabla equivalencias pone los tres lado a lado.

La regla de la sala anterior se aplica al formato: en OpenVEX, un not_affected necesita al menos una justificación o una declaración de impacto. Un affected debería llevar una declaración de acción. Lo demás, como el autor, la fecha o la versión del documento, viaja en la cabecera.

Mira las seis declaraciones recibidas, ya reducidas a su estado y a lo que traen. Una de las de OpenVEX no cumple la regla del no afectado.

En CSAF, un documento que declara pertenecer al perfil VEX debe cumplir condiciones propias. Para cada producto en known_not_affected tiene que existir una declaración de impacto: una etiqueta legible por máquina en flags o un texto en threats con categoría impact. Para cada producto en known_affected tiene que existir información específica, la acción, en remediations. La etiqueta de flags usa las mismas cinco justificaciones que ya conoces.

Una de las declaraciones CSAF de la tabla incumple el perfil.

La equivalencia entre formatos es buena para leer, pero no perfecta. CycloneDX tiene el estado false_positive, para cuando la vulnerabilidad no es propia del componente y se asoció por error, y resolved_with_pedigree, para una corrección con historial verificable de cambios. Ninguno de los dos tiene pareja exacta en OpenVEX ni en CSAF. Un lector que convierta formatos automáticamente debe decidir qué hace con esos estados, y la decisión no es obvia.