Docker VEX is a way to tell vulnerability scanners whether a known CVE is actually exploitable in a specific container image. In 2026, this matters because teams face too many alerts and too little remediation time. The key takeaways: scan continuously, use VEX to suppress non-exploitable findings, and still patch real reachable risk quickly.
Container vulnerability noise is a real problem because scanners often report every CVE present in a package, even when the vulnerable code path is not reachable, not loaded, or not exploitable in that image. Security teams then spend hours debating scanner output instead of fixing the vulnerabilities that can actually be attacked.
Docker announced enhanced vulnerability scanning for Docker Hardened Images with Aikido and VEX support in June 2026. The important idea is not merely another scanner. It is better prioritization: verified non-exploitable findings can be removed from the active queue so teams focus on real risk.
The scale is large. The National Vulnerability Database regularly adds tens of thousands of CVE records per year, and CISA’s Known Exploited Vulnerabilities catalog highlights the subset confirmed to be exploited in the wild. That gap explains why raw CVE count is a weak operational metric.
VEX, or Vulnerability Exploitability eXchange, is a machine-readable statement about whether a vulnerability affects a product or artifact in an exploitable way. For containers, VEX helps explain whether a CVE found in a package is relevant to the running image.
The Cybersecurity and Infrastructure Security Agency describes VEX as a companion to software bills of materials because SBOMs show what is present, while VEX can show whether a vulnerability is exploitable. That distinction is crucial for container images built from many operating system packages, language dependencies, and build-time tools.
A simplified VEX-style decision might look like this:
{
"cve": "CVE-2026-EXAMPLE",
"artifact": "registry.example.com/app/api:1.4.2",
"status": "not_affected",
"justification": "vulnerable_component_not_in_execute_path"
}
This does not mean ignoring security. It means documenting why a specific finding is not exploitable and preserving that evidence for audit, triage, and future review.
Docker Hardened Images scanning uses VEX-style context to reduce false positives and identify vulnerabilities that deserve action. Docker’s June 2026 announcement says the enhanced workflow combines Docker Hardened Images, Aikido analysis, and VEX so verified non-exploitable findings can be automatically filtered.
That is valuable because hardened images are already designed to reduce attack surface. If an image has fewer packages, minimal defaults, and clearer provenance, the scanner has less noise to process. VEX then adds context about exploitability so teams can avoid repeatedly triaging the same irrelevant CVEs.
For small teams running WordPress, APIs, or SaaS workloads, the lesson is broader than one Docker product: choose smaller base images, generate SBOMs, scan in CI, and document exploitability decisions. Do not treat a scanner score as the only truth.
You reduce false-positive CVEs by combining minimal images, SBOMs, exploitability context, and clear remediation rules. The goal is not fewer alerts at any cost. The goal is fewer wrong alerts and faster action on the right ones.
# Example CI policy concept
if cve in CISA_KEV and image_exposed_to_internet:
block_release()
elif vex_status == "not_affected":
document_and_continue()
else:
require_security_review()
Patch CVEs first when they are exploited in the wild, reachable in your runtime, internet-facing, privilege-escalating, or present in a high-value service. CVSS is useful, but it should not be the only priority signal.
A high CVSS vulnerability in a build-only package may be less urgent than a medium vulnerability in a public authentication service. Likewise, a CVE listed in CISA KEV deserves fast attention because it has known exploitation evidence. Docker’s enhanced scanning direction reflects this reality: security operations need context, not just volume.
Named authority matters here. CISA’s KEV catalog states that listed vulnerabilities are confirmed to have been exploited in the wild and should be remediated according to binding operational directives for U.S. federal agencies. Even for private teams, that is a strong prioritization signal.
The biggest risk is using VEX as a way to hide vulnerabilities instead of documenting exploitability. A bad VEX process can create false confidence if statements are not evidence-backed, reviewed, or tied to immutable image digests.
Require a justification for every not-affected decision. Store who made the decision, what evidence was used, and when it expires. If a new app version starts using a previously dormant library, the VEX status must be revisited. For regulated teams, align VEX records with SBOMs, change management, and incident response procedures.
No. VEX means you can document exploitability context. Real, reachable, or exploited vulnerabilities still need remediation.
No. VEX is a broader vulnerability context format. Docker’s announcement is one practical implementation for container image scanning.
An SBOM lists components. VEX explains whether vulnerabilities in those components affect a specific product or artifact.
Yes, if scanner noise is slowing remediation. Even a lightweight VEX-like review note is better than repeatedly triaging the same non-exploitable alert.
Known exploited vulnerabilities, reachable remote code execution, exposed authentication bugs, and unreviewed critical findings should usually block deployment.
Internal reading suggestions: Linux Kernel CVE guidance, WordPress plugin update delay security, and HTML-First Development.