VEX y un aviso nuevo

Cuando sale un aviso nuevo, la primera consulta no es el código: es el inventario. Con un SBOM por servicio y versión, saber «¿lo llevamos, y en qué versión?» es leer unos archivos, no una investigación. Se busca el componente en cada inventario, se compara la versión con el rango del aviso (la aritmética de la segunda sala) y se obtiene la lista de productos que hay que mirar de cerca. Los que no lo llevan se descartan con evidencia: el componente no está presente.

La rapidez de esa respuesta es lo que un SBOM al día compra.

VEX significa Vulnerability Exploitability eXchange: un documento, que acompaña al SBOM, donde quien publica un producto declara, para cada aviso, el estado del producto. Los estados que define OpenVEX son cuatro: not_affected (no hace falta actuar), affected (se recomienda actuar), fixed (esas versiones ya traen la corrección) y under_investigation (aún no se sabe). Cuando el estado es not_affected, hay que dar una justificación de una lista cerrada, por ejemplo component_not_present, vulnerable_code_not_present o vulnerable_code_not_in_execute_path. CycloneDX expresa lo mismo en otro vocabulario, en su campo de análisis de cada vulnerabilidad.

El VEX no sustituye a nada: es la respuesta del proveedor a la pregunta «¿y a mí me afecta?» que el SBOM por sí solo no contesta.

Un VEX es un compromiso: quien lo recibe actúa sobre lo que dice. Por eso se revisa antes de enviarlo con una regla mecánica: toda declaración not_affected necesita justificación, y la justificación debería poder apoyarse en una evidencia que exista. El borrador de Algarrobo tiene una declaración not_affected sin justificación: o falta el motivo, o el estado no es el correcto. Un producto que ya lleva la versión corregida no está «no afectado»: está corregido, que es otra cosa y obliga a otra frase.

Aísla la declaración defectuosa y di de qué servicio habla.

Una justificación sin evidencia es una opinión. En el borrador, una de las declaraciones cita el informe de alcance que respalda su afirmación; otra se apoya en que el componente no está en el inventario. La primera es la más delicada, porque si el código cambia, la evidencia caduca, y el VEX debe actualizarse con ella. Cada declaración debería poder responder a quien la lea: «¿en qué archivo lo compruebo?».

Aísla la declaración que se apoya en un informe de alcance.

Con el rango del aviso nuevo y el inventario de los cuatro servicios se sabe cuántos productos hay que atender. Se cuentan los servicios cuyo componente cae dentro del rango afectado: los que llevan una versión anterior al rango, o la ya corregida, o no lo llevan, no cuentan. Es el cálculo que sostiene el primer mensaje que se manda a quien pregunta por el aviso: «afecta a N de nuestros servicios, estos».

Hazlo con el rango del archivo del aviso y las versiones de cada inventario.