Aikido now scans Docker Hardened Images (DHI) with built-in VEX support. Vulnerabilities that Docker has verified as non-exploitable drop out of the queue automatically, so developers spend their time on findings that actually matter. This post walks through what changed, why it matters, and how users can benefit from the new integration.
Why teams are drowning in CVEs
Modern application teams drown in CVEs. And the volume is climbing fast. AI coding agents now generate and assemble software far faster than any team can review it, pulling in dependencies by the hundreds and spinning up new services on demand. Every base image they reach for is another stack of CVEs landing in someone’s queue. The faster code ships, the more it matters that it starts from a foundation that’s already minimal, already patched, and already vetted — which is exactly why hardened images matter more now than they ever have.
Docker Hardened Images addresses this problem at the source. DHI images are purpose-built, often distroless, and ship with only the software the workload needs. The attack surface is smaller by construction. Patches land faster than upstream in many cases.
A smaller attack surface only helps if your scanner can see it. Distroless images break tools that expect a package manager or a shell. Naive scanning produces false positives against components that are not actually present, or flags CVEs in code paths that cannot be reached. Teams end up triaging noise that the image author already knew was not a problem.
The new integration closes this gap. DHI publishes signed VEX attestations alongside each image. Aikido reads those attestations and applies them during triage. The CVEs Docker has already cleared get filtered out, with a clear reason attached.
Before you begin
You need three things to scan DHI with Aikido:
An active Aikido account.
Access to Docker Hardened Images.
A Docker Hub Personal Access Token with read-only scope.
If your Docker Hub registry is already connected to Aikido, skip the next section.
Connect Docker Hub to Aikido
In Aikido, go to Settings > Containers and click Connect Registry.Select Docker Hub.Enter your organization namespace, username, and Personal Access Token.Aikido discovers your repositories and lists them for scanning.
Scan a Docker Hardened Image
Once the registry is connected, open the registry action menu and click Scan repos in registry. There is no extra configuration for DHI. Aikido detects hardened images automatically and applies the right data sources in the background.
Under the hood, the workflow follows the DHI technical spec:
Detection. Aikido identifies the DHI base image from the image reference and registry metadata.
Cataloging. The scanner pulls the signed SPDX 2.3 SBOM published with the image. SBOMs are retrieved through OCI 1.1 referrer lookup against the registry, or from /opt/docker/sbom/ when present. Reading the vetted SBOM produces complete, accurate component data, where indexing a distroless filesystem would not.
Matching. Components are matched by PURL against the Docker OSV feed and upstream advisory feeds.
Applying VEX. Aikido overlays the OpenVEX statements Docker publishes for the image, and suppresses any finding marked as resolved by the attestation.
How VEX status shows up
VEX status
What it means
Fixed
The vulnerability is patched in this image.
Not Affected
Docker has verified the CVE is a false positive or non-exploitable in context. Aikido suppresses these by default.
Under Investigation
Impact is still being assessed by Docker.
Affected
The vulnerability applies, and a fix is not yet available.
What you see in Aikido
Aikido keeps the UI focused on a single question: is this image vulnerable or not. When Docker’s VEX attestation indicates a CVE doesn’t require triage (for example, it’s been fixed or marked not affected), Aikido filters it out of the active queue automatically. You don’t have to triage it, tag it, or click through anything. Findings that remain in the queue are the ones that genuinely apply to the image, so your team spends time only on what matters.
Behind the scenes, Aikido still consumes the full OpenVEX statement (status, justification, image digest) for audit and compliance purposes. It just isn’t surfaced as a status drill-down in the UI, because in practice nobody triaging vulnerabilities wants to dig through VEX metadata.
What the result looks like
On a typical DHI workload, the active queue shrinks dramatically once VEX is applied. A scan that returns several hundred CVEs against a generic base image collapses to the handful of findings the image actually carries.
A concrete example: a CVE in a parser library shows up across most base images. Docker marks it not_affected in the DHI build because the vulnerable code path cannot be reached by an adversary. Aikido reads that statement, files the CVE under “VEX indicates not affected,” and your team never sees it in triage. The justification stays attached if an auditor asks.
For teams pursuing FedRAMP, SOC 2, or other compliance regimes, this matters twice. The findings list is honest. The exceptions are signed, attributable to the image publisher, and traceable back to a public attestation. You are not handing auditors a wall of red.
Recap
The integration is based on the following information provided by Docker Hardened Images:
Signed SBOMs give Aikido complete component data without trying to index a distroless filesystem.
OpenVEX attestations carry Docker’s exploitability verdict, with justification, directly into the scanner.
The outcome is a triage queue that reflects real exploitability in your image, not a flat dump of every CVE that ever touched an upstream package.If you have not started with hardened images yet, the Docker Hardened Images documentation is the place to begin.
Learn more about the integration:
On June 26th, Aikido is hosting a webinar for those interested in learning more about the integration.
Register for Aikido x Docker: Less Noise, More Signal in Container Security
Resources
Review our Docker Hardened Images documentation.
Set up Docker Hub registry on Aikido
Quelle: https://blog.docker.com/feed/
