Exploitability Needs Runtime Evidence: Understanding Runtime Vulnerability Reachability for Containers
Table of Contents
Key Takeaways
- Qualys Runtime Vulnerability Reachability for Containers brings runtime evidence directly into vulnerability prioritization.
- Package presence in a container image does not mean the vulnerable software is actually part of the workload’s live execution.
- Runtime reachability answers whether the vulnerable software is relevant to a running workload, a different question from whether the vulnerability is theoretically exploitable.
- Qualys retains runtime evidence over an observation window rather than a single point-in-time snapshot, so software that mattered yesterday is not missed today.
- Runtime evidence works alongside CVSS, the CISA KEV catalog, EPSS, exposure analysis, and exploit validation to build a fuller picture of real-world risk.
- The approach aligns with CISA’s direction under Binding Operational Directive (BOD) 26-04 toward prioritizing by likelihood and consequence of exploitation rather than static severity alone.
Finding vulnerabilities has never been easier. Determining which ones are actually exploitable in your environment is still hard.
The industry has built increasingly sophisticated ways to answer that question. The Common Vulnerability Scoring System (CVSS) measures severity. The Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities Catalog (CISA KEV) tells us whether attackers are exploiting vulnerabilities in the wild. The Exploit Prediction Scoring System (EPSS) estimates the likelihood of exploitation. Exposure analysis tells us whether an attacker can reach the affected workload. Exploit validation can prove that a vulnerability can be successfully exploited under a particular set of conditions.
All of these signals matter. But they still leave an important question unanswered: is the vulnerable software actually part of the application running in production?
Qualys Runtime Vulnerability Reachability for Containers brings runtime evidence directly into vulnerability prioritization. By correlating vulnerabilities with software observed in the running workload and retaining that evidence over time, Qualys helps security teams distinguish between vulnerabilities that simply exist inside an image and those that are actually relevant to the workload’s execution.
From Theoretical Exploitability to Runtime Exploitability
A modern container image can contain hundreds of operating system packages, libraries, and transitive dependencies. Vulnerability scanning can accurately identify the Common Vulnerabilities and Exposures (CVEs) associated with those components, but package presence alone does not mean an attacker will ever encounter the vulnerable software.
This creates an important distinction between theoretical exploitability and runtime exploitability.
Exploit validation can demonstrate that a vulnerability is exploitable when the required conditions exist. That answers an important question: Can this vulnerability be exploited?
Runtime reachability answers another: Is the vulnerable software actually relevant to this workload?
For remediation prioritization, this context can be equally important or, in some cases, even more important.
A publicly available exploit may affect a package present across thousands of container images, while only a subset of those applications ever use the affected software. Conversely, vulnerable software repeatedly observed in an internet-facing production workload provides strong evidence that the affected component is part of the application’s live execution footprint.
Exploitability is therefore not simply a property of a CVE. It is a relationship between the vulnerability, the software, the workload, and the environment in which it runs.
Runtime provides evidence of that relationship.
Understanding Runtime Vulnerability Reachability
Qualys Runtime Vulnerability Reachability connects container vulnerability assessment with actual workload behavior. When vulnerable software is observed in the running workload, Qualys associates that runtime evidence with the corresponding vulnerabilities, helping teams understand which findings are relevant to the applications executing in production.
But the runtime cannot be treated as a single point-in-time snapshot.
Applications exercise different code paths at different times. A library may load at startup, during a scheduled process, or only when a particular Application Programming Interface (API) is invoked. If runtime validation looks exclusively at what is active at one instant, software that was important yesterday could appear irrelevant today.
That is why Qualys retains runtime reachability evidence across an observation window. Teams can understand whether vulnerable software has been observed in runtime over that window, rather than relying solely on what is loaded at the time of investigation.
This historical context turns runtime from a transient signal into durable evidence for vulnerability prioritization.
The example below shows this in practice. Filtering the dvwa-web-server container for CISA KEV vulnerabilities whose vulnerable packages have been observed in use over the last seven days (vulnerabilities.vulnerable.packages.inuse:[now-7d ... now]) narrows the results to four Critical Debian findings with available patches, including QID 178815 affecting apache2-bin.
Each of these four findings is tied to a package observed in the running workload within that window. A vulnerable package repeatedly observed in runtime over the last seven days should carry a different weight from software that has existed inside an image for months but has never been observed as part of the running workload.
How Qualys Thinks About Exploitability
Real-world exploitability emerges when multiple pieces of evidence converge.
CISA KEV can tell us that attackers are already exploiting a vulnerability. Exploit intelligence can indicate whether exploitation is practical or automated. Exposure analysis can determine whether an attacker has a path to the workload. Runtime reachability establishes whether the affected software is relevant to that workload. Attack path and business context can show what an attacker could reach after a compromise.
Combining these signals quickly narrows the focus. In the view below, the same container is filtered for internet exposure, CISA KEV status, and QID 178815. The result is a single running, publicly exposed workload, dvwa-webserver, with a TruRisk score of 305.
Consider two containers affected by the same Critical CISA KEV vulnerability, such as QID 178815. Both contain the same vulnerable package, and both may have a working public exploit. In one container, the affected software has never been observed in runtime. In the other, like the dvwa-web-server workload above, it has been observed in runtime within the last seven days in an externally exposed production workload.
The vulnerability is the same. Its theoretical exploitability is the same. The operational risk is not.
This is why runtime evidence can become one of the strongest signals for determining what security teams should remediate first. Exploit validation establishes the possibility. Runtime reachability establishes relevance. Exposure establishes opportunities. Threat intelligence establishes attacker activity.
Together, they provide a much stronger picture of exploitability than any one signal alone.
Aligning Vulnerability Prioritization to Real-World Risk
This approach aligns closely with the direction CISA is taking vulnerability management through BOD 26-04.
Rather than prioritizing vulnerabilities mainly by static severity, CISA considers factors such as:
- Public exposure
- Inclusion in the Known Exploited Vulnerabilities (KEV) Catalog
- How easily an exploit can be automated
- The technical impact of a successful compromise
The broader principle is important: remediation decisions should increasingly reflect the likelihood and consequence of exploitation, not simply the severity assigned to a CVE.
Runtime reachability adds environmental evidence to that model.
A vulnerability that is externally exposed, present in CISA KEV, and associated with software actively observed in runtime, represents a fundamentally different remediation priority from a high-severity vulnerability buried inside an unused package.
Security teams can be more effective in their risk remediation by moving beyond asking which vulnerabilities are critical and instead focusing on where the strongest evidence of exploitability is accumulating.
Exploitability Is a Continuum, Not a Checkbox
The next evolution of vulnerability management will not come from finding more vulnerabilities or producing another standalone risk score. It will come from increasing confidence behind every remediation decision.
With Runtime Vulnerability Reachability for Containers, Qualys is bringing runtime evidence directly into vulnerability management and preserving that evidence over time, helping organizations prioritize vulnerabilities based on how software behaves in production.
Because the most important question is no longer simply whether a vulnerability can be exploited.
It is whether the evidence of exploitation risk is converging in your environment.
Meet Qualys Cloud and Container Security experts at ROCon Americas, Oct. 13–15, in Austin, Texas.
Frequently Asked Questions (FAQs)
What is Runtime Vulnerability Reachability for Containers?
It correlates container vulnerabilities with software observed in the running workload and retains that evidence over an observation window, so teams can separate image presence from live relevance.
Is runtime reachability the same as exploit validation?
No. Exploit validation asks whether a vulnerability can be exploited when conditions exist. Runtime reachability asks whether the vulnerable software is relevant to this workload.
Why not use a single point-in-time snapshot?
Code paths load at different times. A library used yesterday can look idle at the moment of investigation. Qualys keeps evidence across the window.
How does this relate to CISA BOD 26-04?
BOD 26-04 pushes prioritization toward likelihood and consequence. Runtime evidence is one environmental input alongside KEV, exposure, and ease of automation.
Does “not observed in runtime” mean the CVE is safe to ignore?
No. It means the finding is lower priority than the same CVE observed in a live, exposed workload. Unused packages can still matter after a code-path change. Revisit them on the observation window, do not delete them from the backlog.
Contributors
- Sachin Kesarkar, Senior Technical Product Manager, Container Security, TotalCloud