# 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](/dhi/explore/scanner-integrations/).
Para escanear una DHI con soporte para VEX, consulta [Escanear Docker Hardened
Images](/dhi/how-to/scan/).

## 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](/dhi/how-to/scan/).

### 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`.