Ask two platform teams how many CVEs are in their images, and you will get numbers that differ by an order of magnitude, not because one team is more secure but because they are counting differently. One scans the full filesystem, the other scans only what is reachable at runtime. One counts every advisory; the other counts what the distro has marked as not affected. Both are honest, and neither number tells you much on its own.
What matters underneath the counting is the mechanism. There are only a few ways a vulnerability leaves an image: the package containing it is not there; the package is rebuilt against a fixed version; the vulnerable code path is provably unreachable and documented as such; or someone decides to stop looking at it. The first three reduce risk. The fourth reduces the number on the dashboard.
What “Eliminating” a CVE Actually Means
Every zero-CVE claim resolves to one of four outcomes, and they are not equivalent.
- The component is absent. No shell, no package manager, no curl, no build toolchain in the runtime image. A vulnerability in software that was never shipped cannot be exploited or flagged. This is the only outcome that is permanently true.
- The component is rebuilt against a fixed version. The package is still present, patched to a release without the known flaw. Durable until the next advisory, which means the value depends entirely on how fast the rebuild happens next time.
- The vulnerability is not applicable. The code is present but the affected function is never called, or the distro backported the fix without changing the version string. Legitimate, and only meaningful when it is machine-readable through VEX rather than a note in a spreadsheet.
- The finding is suppressed. An exception, an ignore file, a policy that fails the build only on critical severity. This is a decision to accept risk, and it is worth being honest that it is not remediation.
Reading a vendor claim through this lens is a useful discipline. A tool that gets an image to zero by absence behaves very differently over six months from one that gets there by triage.
The 6 Tools That Eliminate CVEs From Container Images
1. Echo
Mechanism: Absence and continuous rebuild, applied to both OS packages and application libraries
Echo takes the position that the most efficient vulnerability workflow is to have no vulnerability to work on. Its images are built minimal by construction, with no shell, package manager, or extraneous tooling in the runtime layer, and then continuously rebuilt as upstream fixes land rather than on a release train. The company reports elimination of more than 99 percent of vulnerabilities across its catalog and customers running zero CVEs on their own CNAPP dashboards, which is the number that matters because it is measured by the customer’s tool rather than the vendor’s.
The part that distinguishes it from other hardened image programs is its scope. Most of this category stops at the operating system layer, which is roughly where the easy half of the problem sits. Echo applies the same treatment to application libraries in the npm and PyPI ecosystems, where the dependency graph is deeper, the churn is faster, and the majority of remaining findings live once the base image is clean. The catalog extends to VMs, serverless artifacts, and OS packages, with Helm charts and EOL support for the software that regulated environments cannot simply upgrade away from.
For teams with compliance obligations, the artifacts are FIPS-validated and STIG-hardened; Echo operates as a CVE Numbering Authority; and customers report reaching FedRAMP readiness roughly 10 times faster than through internal hardening. Adoption is a single line change in a Dockerfile, since the images are drop-in compatible, and teams that previously maintained golden images internally report saving hundreds of engineering hours a year. Varonis is among its named customers.
How it reduces CVEs:
- Minimal runtime images with no shell, package manager, or build tooling present
- Continuous agent-driven rebuilds as upstream fixes are published
- A defined SLA for handling newly disclosed CVEs
- FIPS-validated and STIG-hardened builds for regulated environments
- Drop-in replacement requiring one line in the Dockerfile
2. Google Distroless
Mechanism: Absence, achieved by shipping only the application and its runtime dependencies
Distroless popularized the idea that most of a container image is software nobody intended to ship. The images contain the language runtime and its dependencies and essentially nothing else, so a scan finds very little because there is very little to find. For Go, Java, Python, and Node workloads this removes a substantial share of typical findings at no licence cost.
The trade-off is operational rather than technical. Without a shell there is no exec into a running container, debugging requires ephemeral debug containers or the separate debug variants, and the images ship as an open source project rather than with a support contract or remediation commitment. Teams adopt it happily and then own whatever remains themselves.
How it reduces CVEs:
- Removes shells, package managers, and userland utilities from the runtime image
- Language-specific variants covering common runtimes
- Smaller images with a correspondingly smaller attack surface
- No licensing cost and wide community familiarity
3. Cloud Native Buildpacks
Mechanism: Rebase, patching the OS layer without rebuilding the application
Buildpacks separate the application layer from the base image so cleanly that the base can be swapped underneath thousands of images without rebuilding any of them. When a base image CVE is fixed, a rebase updates the affected layer directly, which turns a rebuild campaign across every service into a mechanical operation measured in minutes.
For organizations with many similar services, this is a genuinely strong answer to patch velocity, and it removes the Dockerfile from the equation entirely. It manages how quickly fixed packages reach production rather than reducing what is in the image in the first place, so the vulnerability count still depends on the base image chosen underneath it.
How it reduces CVEs:
- Rebase of the OS layer across many images without application rebuilds
- Consistent, reproducible builds without hand-written Dockerfiles
- Automatic SBOM generation as part of the build
- Substantially shorter time between an upstream fix and production
4. JFrog
Mechanism: Curation, blocking vulnerable components before they enter the registry
JFrog approaches the problem at the point of entry. Its platform combines artifact management with scanning and curation policy, so packages that violate policy are blocked from being pulled into the organization at all rather than discovered in an image weeks later. Preventing a bad dependency from crossing the perimeter is considerably cheaper than tracing it afterwards through every image that consumed it.
It also provides deep contextual analysis to distinguish vulnerabilities that are actually reachable from those merely present, which reduces the triage burden meaningfully. It governs and analyzes what teams consume rather than producing hardened artifacts, so the quality of the upstream sources still sets the ceiling.
How it reduces CVEs:
- Policy-based curation blocking vulnerable packages at ingestion
- Scanning across images, dependencies, and binaries in the registry
- Contextual analysis separating reachable findings from present ones
- Full artifact lineage across the software supply chain
5. Aqua Security
Mechanism: Detection and prioritization across the build pipeline and registry
Trivy has become the default scanner in a great many pipelines, and the Aqua platform around it extends detection across images, filesystems, repositories, and infrastructure as code, with prioritization and policy enforcement layered on top. Nothing in this list removes the need for independent verification, and this is the tool most teams verify with.
Detection is necessary and, by definition, not sufficient. A scanner tells you the image contains a vulnerable OpenSSL and cannot make that package go away, so its output is only as valuable as the remediation path behind it. Used alongside a source of clean artifacts, it becomes verification. Used alone, it becomes a backlog.
How it reduces CVEs:
- Comprehensive scanning across images, filesystems, and IaC
- Prioritization based on exploitability and runtime context
- Policy gates that fail builds against defined thresholds
- Independent verification of vendor-supplied hardened images
6. Amazon ECR with Inspector
Mechanism: Continuous monitoring of images already sitting in the registry
The failure mode nobody plans for is the image that was clean at build time and became vulnerable three weeks later when a new advisory landed. Enhanced scanning in Amazon ECR, backed by Inspector, rescans stored images automatically as vulnerability data changes and pushes findings into the surrounding AWS security tooling.
For teams already on AWS this is close to free operational hygiene and it covers a real gap in build-time-only scanning. It is monitoring rather than remediation, and it inherits the boundaries of the platform, so multi-cloud estates need a comparable mechanism elsewhere.
How it reduces CVEs:
- Automatic rescanning of stored images as new advisories are published
- Findings routed into existing AWS security workflows
- Coverage of OS packages and common language dependencies
- No additional scanning infrastructure to operate
Where the Remaining CVEs Come From
Teams that harden their base images successfully are often surprised by what is left. The composition of the remaining findings is fairly consistent.
- Application dependencies. Once the OS layer is clean, most remaining findings sit in npm, PyPI, Maven, or Go modules pulled in by the application. This is usually the larger half of the problem and the half that base image hardening does not touch at all.
- Transitive depth. The direct dependency list is short and the resolved tree is not. Findings arrive from packages nobody chose, three or four levels below anything in the manifest.
- End-of-life components. Software past upstream support keeps accumulating advisories and stops accumulating fixes. Regulated environments frequently cannot upgrade on the timeline that would solve this.
- Build tooling left in the runtime image. Compilers, package managers, and debugging utilities that were needed to build the artifact and then shipped with it. Multi-stage builds solve this, and single-stage Dockerfiles remain common.
The practical implication is that base image selection and dependency hygiene are one problem rather than two. Solving only the first produces a much shorter findings list that still never reaches zero.
Frequently Asked Questions
Can a container image genuinely have zero CVEs?
Yes, for known vulnerabilities at a point in time, and that qualifier carries weight. Zero means no component in the image has a published advisory today. Tomorrow’s disclosure can change that without anything in the image changing, which is why rebuild cadence matters more than any single scan result.
Why do two scanners report different CVE counts for the same image?
They use different vulnerability databases, identify packages differently, and apply distro-specific fix status differently. A backported fix that leaves the version string unchanged is a common source of disagreement, as is whether the scanner counts application dependencies alongside OS packages.
Do minimal images break debugging?
They change it. Without a shell you cannot exec into a running container, so debugging moves to ephemeral debug containers, sidecars, or separate debug image variants. Most teams adapt within a sprint, and the workflow change is the main cultural obstacle to adoption.
Is scanning still necessary with hardened images?
Yes. Independent verification is sound practice regardless of the source, compliance frameworks generally require evidence of scanning, and no supplier covers every component in every image. The difference is that scanning becomes confirmation rather than the start of a remediation queue.
What does hardening the base image not fix?
Application dependencies, which typically account for the majority of findings once the OS layer is clean. A minimal base with a large npm or PyPI dependency tree still produces a long list, which is why coverage across both layers matters more than depth in either one.
How disruptive is switching base images?
Less than most teams expect when the replacement is drop-in compatible, since the change is a line in the Dockerfile and a CI run to confirm the build. Effort concentrates where images assumed a shell or package manager at runtime, which is worth auditing before a wide rollout rather than discovering service by service.
What should a team measure to know this is working?
Three numbers say more than a total count. Mean time from an upstream fix being published to the patched artifact reaching production, the proportion of findings closed by absence or a rebuild rather than by exception, and how many findings arrive per rebuild cycle compared with how many the team can genuinely assess. A falling total with a growing exception list is not progress.
