Intercambio de explotabilidad de vulnerabilidades (VEX)
¿Qué es VEX?
El Intercambio de explotabilidad de vulnerabilidades (VEX, Vulnerability Exploitability eXchange) es una especificación para documentar el estado de explotabilidad de las vulnerabilidades dentro de los componentes de software. VEX se define principalmente a través de estándares de la industria como CSAF (OASIS) y CycloneDX VEX, y la U.S. Cybersecurity and Infrastructure Security Agency (CISA) promueve su adopción. VEX complementa los identificadores de CVE (Common Vulnerabilities and Exposures) agregando información de estado afirmada por el proveedor, la cual indica si una vulnerabilidad es explotable en el producto tal como se distribuye. Esto ayuda a las organizaciones a priorizar los esfuerzos de remediación al identificar vulnerabilidades que no afectan a las configuraciones específicas de sus productos.
Para ver cómo afecta VEX al recuento de vulnerabilidades y a la selección de escáneres, consulta Integraciones de escáneres. Para escanear una DHI con soporte para VEX, consulta Escanear Docker Hardened Images.
Referencia de estados VEX
Cada declaración VEX incluye un campo status que registra la evaluación de
explotabilidad de Docker para una CVE e imagen dadas. DHI utiliza tres de los cuatro
valores de estado de OpenVEX.
| Estado | Significado |
|---|---|
not_affected | La CVE se reportó contra un paquete de la imagen, pero Docker ha determinado que no es explotable tal como se distribuye |
under_investigation | Docker tiene conocimiento de la CVE y está evaluando activamente si afecta a la imagen |
affected | Docker ha confirmado que la CVE es explotable en la imagen y aún no hay una solución disponible |
Puedes ver las declaraciones VEX para cualquier DHI utilizando Docker Scout. Consulta Escanear Docker Hardened Images.
Códigos de justificación de not_affected
Las declaraciones de not_affected incluyen un campo justification legible por
máquina que explica por qué no se aplica la vulnerabilidad:
| Justificación | Significado |
|---|---|
component_not_present | El componente vulnerable no está presente en esta imagen; la CVE coincidió por nombre con un paquete diferente |
vulnerable_code_not_present | La ruta de código vulnerable no se compiló en esta construcción |
vulnerable_code_not_in_execute_path | El código vulnerable existe en el paquete, pero no se invoca en la configuración de ejecución de esta imagen |
vulnerable_code_cannot_be_controlled_by_adversary | El código vulnerable existe, pero un atacante no puede activarlo en esta configuración |
inline_mitigations_already_exist | Docker ha aplicado un backport o parche que soluciona la CVE |
Por qué DHI no utiliza fixed
DHI no utiliza fixed. Los escáneres compatibles con VEX pueden no procesar fixed
de manera consistente; por ello, cuando Docker realiza un backport de un parche
ascendente (upstream) donde el número de versión por sí solo no reflejaría la solución,
utiliza en su lugar not_affected con la justificación inline_mitigations_already_exist.