The Next Stage Of Container Security Is Knowing Which CVEs Actually Matter

Discover which CVEs actually have significance in determining the future of Container Security. This tutorial will guide you to gain deep insights on how to overcome Container Security Vulnerabilities effectively:

Container security teams are quite adept at identifying vulnerabilities. The more difficult part is determining which results are worth paying attention to right away. While a modern scanner can detect hundreds or thousands of CVEs in a large container estate, a long list of CVEs doesn’t necessarily equate with a long list of potential real-world threats.

This separation is gaining significance in the face of growing volumes of vulnerabilities. In 2025, 48,185 CVEs were published, up 20.6% from the previous year’s 39,962.

Container Security Vulnerabilities: Smarter Ways To Handle

The average rate of newly disclosed vulnerabilities is about 130 per day. In organizations with a lot of applications, images, and dependencies, it’s no longer possible to treat every CVE equally as time-critical.

The next step in container security is therefore not about discovering further vulnerabilities, but about figuring out which ones are exploitable.

That means, for teams attempting to build and maintain secure container images, it’s a combination of traditional scanning and runtime context, exploitability data, provenance information, and a better understanding of what code is reachable within production environments.

CVE Volume Has Become a Security Problem of Its Own

The CVE system is still one of the pillars of vulnerability management. It provides a shared method for labeling and talking about publicly revealed vulnerabilities across software ecosystems for security teams. But the size of that system has shifted drastically.

With 48,185 CVEs published in 2025, this marked another year of vulnerability disclosures, extending a seven-year streak of yearly record highs. That growth is good, and it is due to improved discovery and disclosure, but it poses an operational issue.

A container scanner could identify vulnerabilities in an operating system package, runtime, library, or application dependency. Scale that up to hundreds or thousands of deployed images, and security teams may soon end up with more findings than they can realistically probe.

The obvious answer, and the one that has traditionally been used, is to prioritize by severity. A high Common Vulnerability Scoring System (CVSS) CVE is addressed in preference to a medium severity CVE.

While that is still a valid approach, severity is not the most critical question to be answered: is this vulnerability exploitable in this particular container?

A Critical CVE is Not Automatically a Critical Risk

CVSS measures characteristics such as attack complexity, privileges required, and potential impact. It gives a critical technical evaluation of the potential severity of a vulnerability if it were to occur under the right conditions. However, containers are rarely in the same circumstances.

A critical vulnerability may technically exist in a library that is part of a library, but may never be called by the application that is being run. Possibly, the vulnerable package is there because it was inherited from a base image. The binary affected may even be unreachable from the network.

A lower-scoring vulnerability could be a service on the internet that accepts untrusted user input in another container. That could be a much more pressing operational concern. That’s what makes the separation of vulnerability and risk so important in today’s vulnerability management. Context changes everything.

Teams must determine if the impacted component is operational, if any functionality is exposed or vulnerable, if the workload is exposed to the outside world, and if an attacker has a viable path to exploitation.

If those questions are not addressed, organizations can end up investing significant engineering hours in resolving issues that are not necessarily that critical in practice, whilst leaving others that are more serious unaddressed.

Exploitability is Becoming the Missing Layer

A better prioritization can be achieved by adding exploitability intelligence.

Unlike CVSS, EPSS is an exploit prediction scoring system. EPSS is not a technical assessment of severity; it is a model based on data on how likely a published vulnerability is to be exploited in the wild within the next 30 days.

This provides security teams with one more method to distinguish between what risks may exist and what attackers are likely to do.

Experts may handle a vulnerability with a high CVSS score and an extremely low chance of being exploited differently than one targeted by active exploitation attempts.

CISA’s Known Exploited Vulnerabilities catalog provides an even more powerful signal. Vulnerabilities listed in the KEV catalog have evidence of exploitation in the wild.

Federal civilian agencies in the United States must address listed vulnerabilities within a specific timeframe, while CISA encourages other organizations to leverage the catalog as a source for prioritization.

The need for prioritization is so great that NIST itself updated its own NVD workflow in April 2026. CVEs that have been added to the KEV catalog now appear in the list of CVEs that are targeted for enrichment, and NIST will enrich CVEs within one business day.

It’s an interesting turnaround. Even the organizations that are maintaining the vulnerability data now recognize that not all CVE information is equally operationally urgent.

Runtime Context Changes the Meaning of a Vulnerability

The power of contextual prioritization is especially significant in container environments, where there can be a significant gap between what is contained in an image and what actually runs.

A scanner typically scans the contents of an image and looks for packages that are known to have vulnerabilities. That gives security teams a good view, but it doesn’t necessarily indicate whether the impacted code is being run.

Runtime context adds the missing information. Suppose that a container image has 60 CVEs identified. All 60 vulnerabilities could be given to the developers for remediation via traditional vulnerability reporting.

Analysis of the runtimes may show that the application actually used only a few of the affected packages, say 8. Then network analysis may reveal that only three of these are reachable from an external service. But, according to exploit intelligence, one of those three is currently exploited in the wild.

Original problem with 60 vulnerabilities. May include one in the operationally urgent problem. That doesn’t imply that the other 59 should be disregarded forever. It implies remediation can be prioritized based on genuine risk, and not a list of scanner findings.

This is especially helpful for security teams with constrained engineering resources. Each unnecessary patch, test cycle and redeployment ties up resources that could be used for a more meaningful exposure.

VEX Can Explain Why a CVE Does Not Apply

An additional key component of this model is Vulnerability Exploitability eXchange (VEX).

VEX enables software manufacturers to indicate if a known vulnerability impacts a specific product or artifact. Instead of just an alert to the scanner, a VEX statement can help explain that the vulnerable component is there, but not in a way that it can be exploited in the context of its use.

This information is now becoming a part of the container vendor’s security workflow.

Docker Hardened Images support VEX scanning was announced as part of Aikido scanning in June 2026. Docker can thus automatically remove vulnerabilities from remediation queues that it has confirmed cannot be exploited. That puts a different spin on vulnerability scanning.

The scanner is not made to create the most extensive list of vulnerabilities; rather, it is integrated into a filtering process to provide a streamlined and valuable list.

This can also help to mitigate one of the most significant organizational issues in security: alert fatigue. Developers who receive multiple vulnerability tickets that end up being inconsequential may be less likely to listen to security alerts in the future.

The more filtering that is done, the more likely that the alerts that do make it to the engineers actually need action.

Smaller Images Still Matter

Risk-based prioritization doesn’t negate the importance of reducing attack surface. Minimal and hardened container images are important, and will always be, because they minimize the software that must be analyzed first.

A general-purpose image may contain shells, utilities, package managers, and libraries which are useful during development but not required in production. Each new package you add is a new source of vulnerabilities. Hardened and distro-less are attempts to trim that fat.

Docker now provides over 1000 hardened images for Alpine, Debian, databases, runtimes, and infrastructure components. Its hardened images include features such as software bills of materials, provenance data, cryptographic signatures, and VEX metadata.

It’s a simple concept: the fewer unnecessary components there are, the fewer there are to be vulnerable and the less work for security teams.

Minimalism alone isn’t enough to create a zero-vulnerability environment. Essential runtimes, cryptographic libraries, and components of operating systems are still being identified with new vulnerabilities.

That’s why image hardening should go hand in hand with intelligent prioritization.

SBOMs Provide the Inventory Layer

Another key piece of modern vulnerability management is software bills of material.

An SBOM lists the components and dependencies of a software artifact. For containers, it means that security teams can see what libraries, packages, and versions were installed when the image was created. For instance, this is particularly useful if a new vulnerability is revealed.

Organizations don’t have to scan all their applications blindly; they can ask their software inventory which images have the affected component. They can then use that information, along with deployment and runtime information, to find where the real exposure is.

SBOMs thus address the following questions:

The first question is Where is the vulnerable software?

The second question is answered by runtime analysis: is it being used?

The third is answered by exploitability intelligence: is it likely to be attacked by someone?

Those signals, when combined, produce a much more valuable vulnerability management model than severity scoring by itself.

Container Security is Moving From Counts to Decisions

Security dashboards have always been based on numbers: how many vulnerabilities, how many critical vulnerabilities, how many high-severity vulnerabilities, and the average remediation time.

While these metrics are easy to measure, they can promote the wrong behavior. It seems like progress to reduce CVEs in an image from 40 to 10. However, if the 10 that were left are filled with network-facing vulnerabilities that are being exploited, the 30 that were removed were unreachable, and the numbers may not reflect the real security.

The more pertinent question is how much risk has been reduced that can be exploited.

That means that security teams need to bring together several dimensions: severity, exposure, reachability, exploit activity, application importance, and business impact.

If a vulnerability in a public authentication service is present, it should be treated differently than the same vulnerability in a closed test environment.

Those differences must increasingly be reflected in container security.

Automation Will Become Essential

Given the size of a modern software estate, this analysis is too tedious to be done by hand for each finding.

Automated security platforms are going to have to integrate more and more with image scanning, SBOM data, VEX statements, runtime telemetry, EPSS scores, and KEV information into a single prioritization workflow.

It should not be about an organization having 15,000 vulnerabilities and producing a report at the end of it.

For example, it should focus on a few vulnerabilities that are most likely to lead to a meaningful breach path and explain why they warrant immediate attention.

This is where automation can deliver even more value than another scanner.

There is already a lot of vulnerable information in the industry. What organizations need are more hours to decipher all of it.

The Goal is Not Zero CVEs

A container that has no known vulnerabilities is still an appealing target, but relying solely on the number of CVEs (0) to equate to success may be a recipe for complacency.

Moreover, a new image might not have any known vulnerabilities today and be the target of several CVE findings tomorrow when new vulnerabilities are published. Software risk is continuously changing. Thus, security cannot be boiled down to a “perfect scan result at a particular point in time”.

The more sustainable goal is to establish a solution that can rapidly detect new vulnerabilities, assess whether they impact deployed workloads, and prioritize remediation based on real-world exposure.

There are tens of thousands of CVEs being published yearly, and security teams cannot patch them all at once. They shouldn’t have to.

How well organizations can distinguish between theoretical vulnerabilities and practical risks will be the next step in container security. CVEs still need to be found. Understanding which ones are really important is increasingly important.

Research Process: The total time involved to complete and publish this article is approximately 22 hours. This content was created through a structured research approach to ensure accuracy and reliability.

For more related guides, you can explore our range of tutorials below:

Was this helpful?

Thanks for your feedback!