A CVE with a CVSS score of 9.8 appears at the top of the scanner report. The security team prioritizes it immediately. The development team patches the affected library. Three days of engineering time are spent on the remediation.
The library was never called by the application.
This scenario is not rare. It is the most common category of vulnerability management waste in containerized environments. CVSS scores measure the severity of a vulnerability in isolation — assuming the affected component is present, reachable, and exploitable. They do not measure the risk to any specific application based on how that application actually uses the component.
The gap between CVSS score and actual risk to a specific application is the prioritization problem that every security team managing CVE backlogs encounters.
What CVSS Measures and What It Does Not?
The Common Vulnerability Scoring System evaluates vulnerabilities across three metric groups:
Base metrics: Exploitability characteristics (attack vector, attack complexity, privileges required, user interaction) and impact characteristics (confidentiality, integrity, availability). These are properties of the vulnerability itself, not of any specific deployment.
Temporal metrics: Current exploit availability, remediation status. These are properties of the vulnerability’s lifecycle.
Environmental metrics: Modifications based on the user’s specific environment (confidentiality/integrity/availability requirements, existing security controls). These are intended to be customized per organization but are rarely populated in practice.
The critical limitation: base and temporal metrics are computed independent of whether the vulnerable component is in an executed code path. A Critical CVSS score on a logging library applies equally to an application that imports the library to log every request and an application that includes the library in a Dockerfile but never calls a logging function.
The Execution-Path Dimension
The dimension that CVSS does not capture is reachability: whether the vulnerable code can actually be executed by an attacker, given the way the application uses the component.
Reachability has three levels:
Package installed, never imported: The package is in the container image as part of a dependency’s dependency chain or as a base image package. The application code never references it. CVEs against this package have zero reachability.
Package imported, vulnerable function never called: The application imports the package but uses only a subset of its API. The vulnerable function is never in the call graph. CVEs against the vulnerable function have low reachability.
Package imported, vulnerable function in active code path: The application directly calls the vulnerable function in its normal operation. CVEs against this function have high reachability and represent genuine risk.
CVSS scoring does not distinguish between these levels. A 9.8 CVSS score receives the same priority treatment regardless of whether the package is in category 1, 2, or 3.
Runtime-Context Prioritization
The alternative to CVSS-only prioritization uses execution data to filter findings before scoring becomes relevant:
Step 1: Determine what executes. Runtime profiling during representative test execution generates an inventory of packages and functions that are actually called. This is the RBOM (Runtime Bill of Materials).
Step 2: Apply reachability filter. CVEs against packages not in the RBOM have no execution evidence and receive low priority regardless of CVSS score. They can be acknowledged, documented as non-reachable, and deprioritized.
Step 3: Apply CVSS to reachable vulnerabilities. Within the set of CVEs against components that are actually executed, CVSS score is a reasonable prioritization signal. A Critical CVE in an actively called library is genuinely urgent.
Step 4: Eliminate non-reachable CVEs through hardening. Rather than maintaining a backlog of deprioritized non-reachable CVEs, container vulnerability scanning tool hardening removes the packages entirely. The CVE disappears from the scanner output because the package is no longer present.
Real-World Impact
The difference between CVSS-only and runtime-context prioritization is measurable:
Scanner output reduction: Removing packages that are not in the execution path typically eliminates 60-80% of CVE findings. The remaining findings are exclusively against components the application actually uses.
Remediation effort reduction: When the finding set is filtered to reachable CVEs, the remediation backlog is smaller and each item in it represents genuine risk. Engineering time spent on remediation produces proportional risk reduction.
False positive elimination: A scanner report that contains 50 Critical CVEs, 40 of which are in non-executed packages, creates pressure to either remediate unnecessary work or accept Critical findings in a risk register. Filtering by reachability eliminates this false alarm pattern before it reaches the risk register.
Frequently Asked Questions
Why are CVSS scores alone not enough for CVE prioritization in container environments?
CVSS scores measure vulnerability severity independent of any specific deployment — they do not account for whether the vulnerable package is actually executed by the application. A CVSS 9.8 score on a logging library applies equally to an application that calls it on every request and an application that includes it in a Dockerfile but never imports it. CVE prioritization frameworks that rely solely on CVSS scores generate remediation backlogs where the majority of Critical findings are in packages the application never calls.
What is the execution-path dimension that CVE prioritization frameworks should include?
The execution-path dimension captures whether the vulnerable code can actually be reached by an attacker given how the application uses the component. There are three reachability levels: package installed but never imported (zero reachability), package imported but vulnerable function never called (low reachability), and package imported with the vulnerable function in the active code path (high reachability). CVE prioritization frameworks should filter findings by this dimension before applying CVSS scores, routing non-reachable packages to removal rather than the active remediation queue.
How does runtime-context prioritization improve CVE remediation outcomes?
Runtime-context prioritization uses execution data from runtime profiling to filter CVE findings before scoring. Packages not in the Runtime Bill of Materials are deprioritized regardless of CVSS score, while CVEs against actively executed packages receive CVSS-weighted urgency. This approach typically eliminates 60–80% of scanner findings from the active queue, concentrating engineering effort on CVEs that represent genuine risk and reducing remediation waste on packages the application never calls.
What is a practical CVE prioritization framework that improves on CVSS-only approaches?
A practical framework adds execution-path classification as a pre-filter, followed by multi-factor scoring that combines CVSS base score with exploitability intelligence (CISA KEV, EPSS) and workload criticality. Non-executed packages route to automated removal rather than the remediation backlog. Executed packages are tiered by combined score into Critical/immediate, High/planned, and Medium/low priority lanes with defined SLAs. The result is a scanner report containing only genuine risk, where security teams can act on every finding rather than triaging noise.
Building a Better Prioritization Framework
The practical framework that security and development teams can implement:
| Priority Tier | Criteria | Action |
|---|---|---|
| Critical/immediate | High CVSS + in active execution path | Remediate within defined SLA |
| High/planned | High CVSS + imported but not hot path | Plan remediation in next sprint |
| Low/deprioritize | Any CVSS + package not in execution | Document, harden to remove |
| Eliminate | Package not imported | Remove via hardening, no tracking needed |
The hardened container images that result from this process have scanner reports that reflect only genuine risk. Security teams receive findings they can act on. Development teams spend engineering time on remediations that reduce actual exposure.
CVSS scores are not wrong — they correctly characterize vulnerability severity. They are incomplete as a standalone prioritization tool because they have no information about whether the vulnerable code runs in any specific environment. Adding execution context transforms CVSS scores from severity ratings into actionable risk signals.