@@ -17,56 +17,41 @@ indicating whether a vulnerability is exploitable in the product as shipped.
1717This helps organizations prioritize remediation efforts by identifying
1818vulnerabilities that do not affect their specific product configurations.
1919
20- ## Why is VEX important?
20+ For how VEX affects vulnerability counts and scanner selection, see [ Scanner
21+ integrations] ( /manuals/dhi/explore/scanner-integrations.md ) . To scan a DHI with
22+ VEX support, see [ Scan Docker Hardened Images] ( /manuals/dhi/how-to/scan.md ) .
2123
22- VEX enhances traditional vulnerability management by:
24+ ## VEX status reference
2325
24- - Suppressing non-applicable vulnerabilities: By providing product-level
25- exploitability assertions from the supplier, VEX helps filter out
26- vulnerabilities that do not affect the product as shipped .
26+ Each VEX statement includes a ` status ` field that records Docker's
27+ exploitability assessment for a given CVE and image. DHI uses three of the four
28+ OpenVEX status values .
2729
28- - Prioritizing remediation: Organizations can focus resources on addressing
29- vulnerabilities that the producer has confirmed are exploitable in the
30- product, improving efficiency in vulnerability management.
30+ | Status | Meaning |
31+ | ---| ---|
32+ | ` not_affected ` | The CVE was reported against a package in the image, but Docker has assessed it is not exploitable as shipped |
33+ | ` under_investigation ` | Docker is aware of the CVE and is actively evaluating whether it affects the image |
34+ | ` affected ` | Docker has confirmed the CVE is exploitable in the image and a fix is not yet available |
3135
32- - Supporting vulnerability documentation: VEX statements can support audit
33- discussions and help document why certain vulnerabilities do not require
34- remediation.
36+ You can view the VEX statements for any DHI using Docker Scout. See [ Scan Docker
37+ Hardened Images] ( /manuals/dhi/how-to/scan.md ) .
3538
36- This approach is particularly beneficial when working with complex software
37- components where not all reported CVEs apply to the specific product
38- configuration.
39+ ### ` not_affected ` justification codes
3940
40- ## How Docker Hardened Images integrate VEX
41+ ` not_affected ` statements include a machine-readable ` justification ` field
42+ explaining why the vulnerability does not apply:
4143
42- To enhance vulnerability management, Docker Hardened Images (DHI) incorporate
43- VEX reports, providing context-specific assessments of known vulnerabilities.
44+ | Justification | Meaning |
45+ | ---| ---|
46+ | ` component_not_present ` | The vulnerable component is not present in this image; the CVE matched by name against a different package |
47+ | ` vulnerable_code_not_present ` | The vulnerable code path was not compiled into this build |
48+ | ` vulnerable_code_not_in_execute_path ` | The vulnerable code exists in the package but is not called in this image's runtime configuration |
49+ | ` vulnerable_code_cannot_be_controlled_by_adversary ` | The vulnerable code exists but an attacker cannot trigger it in this configuration |
50+ | ` inline_mitigations_already_exist ` | Docker has applied a backport or patch that addresses the CVE |
4451
45- This integration allows you to:
52+ ### Why DHI does not use ` fixed `
4653
47- - Consume producer assertions: Review Docker's assertions about whether known
48- vulnerabilities in the image's components are exploitable in the product as
49- shipped.
50-
51- - Prioritize actions: Focus remediation efforts on vulnerabilities that Docker
52- has confirmed are exploitable in the image, optimizing resource allocation.
53-
54- - Support audit documentation: Use VEX statements to document why certain
55- reported vulnerabilities do not require immediate action.
56-
57- By combining the security features of DHI with VEX's product-level
58- exploitability assertions, organizations can achieve a more effective and
59- efficient approach to vulnerability management.
60-
61- > [ !TIP]
62- >
63- > To understand which scanners support VEX and why it matters for your security
64- > workflow, see [ Scanner integrations] ( /manuals/dhi/explore/scanner-integrations.md ) .
65-
66- ## Use VEX to suppress non-applicable CVEs
67-
68- Docker Hardened Images include VEX attestations that can be consumed by
69- vulnerability scanners to suppress non-applicable CVEs. For detailed
70- instructions on scanning with VEX support across different tools including
71- Docker Scout, Trivy, and Grype, see [ Scan Docker Hardened
72- Images] ( /manuals/dhi/how-to/scan.md ) .
54+ DHI does not use ` fixed ` . VEX-enabled scanners may not handle ` fixed `
55+ consistently, so when Docker backports an upstream patch where the version
56+ number alone would not reflect the fix, it uses ` not_affected ` with
57+ ` inline_mitigations_already_exist ` justification instead.
0 commit comments