SBOM y VEX: componentes e impacto de las vulnerabilidades
Sytance · Actualizado
Una SBOM identifica los componentes de software de un producto. Vulnerability Exploitability eXchange (VEX) comunica si una vulnerabilidad concreta afecta a ese producto. La evaluación depende de la versión del producto, su configuración y la forma en que utiliza el componente.
Inventario de componentes, coincidencias e impacto
El inventario registra si un componente está presente. Una coincidencia de vulnerabilidad indica que un aviso menciona el componente o su versión. El análisis del impacto comprueba entonces si el código vulnerable está presente y puede explotarse en la compilación y el uso reales del producto.
CycloneDX utiliza VEX para comunicar la evaluación de un producto concreto. Por ejemplo, un componente puede estar presente aunque una función vulnerable opcional se haya excluido durante la compilación. Para establecer esa diferencia se necesitan datos y análisis de la compilación.
Los cuatro estados de OpenVEX
OpenVEX define cuatro estados. Cada estado se aplica a la versión del producto y a la vulnerabilidad identificadas en la declaración.
| Estado de OpenVEX | Significado |
|---|---|
| under_investigation | El impacto aún está en evaluación |
| affected | El producto identificado está afectado |
| fixed | La versión identificada incluye una corrección |
| not_affected | El producto identificado no está afectado |
Un decodificador opcional en una pasarela
Considere una pasarela ficticia que contiene una biblioteca de análisis con un decodificador opcional. Suponga que una vulnerabilidad afecta a ese decodificador. La evaluación empieza por determinar qué compilación de la biblioteca está en la imagen distribuida y si el decodificador se compiló en ella.
Si los ajustes de compilación y el análisis del binario confirman que el decodificador vulnerable está ausente, pueden respaldar una declaración not_affected con el motivo vulnerable_code_not_present. La declaración se aplica a esa compilación.
Si el código está presente, pero no está claro si se ejecuta, mantenga la evaluación en investigación mientras comprueba los puntos de entrada y las rutas de ejecución. Si el producto está afectado y una versión posterior incluye la corrección, la versión anterior sigue estando afectada; la versión posterior recibe su propia declaración.
Motivos para el estado not_affected
OpenVEX exige que una declaración not_affected incluya una justificación o una declaración de impacto. Sus justificaciones legibles por máquina distinguen entre componentes ausentes, código vulnerable ausente, código fuera de la ruta de ejecución, límites al control del atacante y mitigaciones integradas.
Cada motivo tiene condiciones distintas. Una restricción de red no elimina el código vulnerable. Para el motivo de mitigación integrada, OpenVEX especifica una protección que impide la explotación y que el usuario no puede desactivar ni reconfigurar.
Para concluir que el código no está en la ruta de ejecución, identifique la función afectada, las rutas comprobadas y las limitaciones de configuración. Revise la evaluación si cambian esas condiciones. Si la conclusión depende de un ajuste controlado por el cliente, comunique claramente esa dependencia.
Uso de una declaración VEX de un proveedor
La declaración VEX de un proveedor puede ayudar a filtrar alertas o cambiar su prioridad. Antes de utilizarla, confirme que la fuente sea de confianza y que coincida la versión del producto. Compruebe la fecha de publicación, las revisiones, la configuración aplicable y las acciones recomendadas.
Si un proveedor de confianza y su propio análisis discrepan, conserve ambos registros y resuelva la diferencia. Una declaración general sobre una familia de productos quizá no cubra una compilación personalizada con componentes u opciones diferentes.
La SBOM sigue siendo útil después de publicar una declaración VEX. Los nuevos avisos pueden cambiar lo que se debe investigar y una versión revisada del producto puede invalidar una conclusión anterior. Mantenga vinculadas las actualizaciones del inventario y las evaluaciones de impacto, pero conserve sus historiales independientes.