CVSS—the Common Vulnerability Scoring System—was designed to provide a standardized severity score for comparing vulnerabilities. It does that reasonably well. What it doesn’t do, despite being used this way constantly, is prioritize which vulnerabilities should be remediated first in a specific environment.
The score represents the theoretical severity of a vulnerability in a generic context. It doesn’t represent the actual risk of the vulnerability in your specific containers, running your specific applications, with your specific exposure profile. The difference between those two things is the gap where vulnerability management programs go wrong.
Why CVSS Fails in Practice?
It ignores runtime context
A CVSS 9.8 critical score means the vulnerability is potentially catastrophic under the right conditions. Those conditions might include: the vulnerable function being called, with attacker-controlled input, through a network-accessible interface, without authentication.
In a specific container running a specific application, many of those conditions may not hold. The vulnerable function may not be in the application’s code path. The package containing the vulnerability may not execute at all during normal application operation—it’s installed as a transitive dependency but never loaded.
CVSS doesn’t know any of this. The score is the same whether the vulnerable function is a central part of your application or a dead code path in a library you never call.
The practical consequence: Teams prioritizing by CVSS score spend significant effort on vulnerabilities in packages that never execute in their production environment, while the actual exploitable vulnerabilities in packages that do execute don’t receive differential priority.
It generates too many “critical” findings
In a container fleet with general-purpose base images, CVSS 7.0+ findings are routine—not because the applications are exceptionally vulnerable but because general-purpose images include many packages with known vulnerabilities, and the CVSS scores for common package CVEs are frequently high.
A fleet that produces 2,000 high-and-critical findings per month cannot prioritize those 2,000 findings by severity, triage each one, and remediate them all on schedule. The scale of CVSS-scored findings exceeds what manual prioritization can process.
It doesn’t reflect current exploitation reality
A CVSS score is assigned when a CVE is published and rarely changes. A vulnerability with a CVSS 7.5 score published three years ago may have active exploit code, be included in the CISA KEV catalog, and be actively used in ransomware campaigns today. A vulnerability with a CVSS 9.0 score may have no public exploit code, no observed exploitation, and limited applicability to real-world configurations.
CVSS doesn’t update to reflect exploitation reality over time. The scores are static; the threat landscape isn’t.
Better Prioritization Signals
Runtime execution context
Container vulnerability scanning tool capability that combines package inventory with runtime profiling data produces a two-tier finding list: CVEs in packages that execute at runtime, and CVEs in packages that don’t.
CVEs in packages that never execute cannot be exploited by an attacker who has no mechanism to load those packages. These findings represent theoretical exposure, not actual exposure. Removing them from the priority queue—or removing the packages themselves—eliminates the backlog entry without any patching work.
This single filter reduces the prioritization workload dramatically for container environments. General-purpose base images with many installed packages see execution rates of 10-25% of installed packages. That means 75-90% of installed packages don’t execute—and their CVEs, regardless of CVSS score, represent theoretical rather than actual exposure.
EPSS (Exploit Prediction Scoring System)
EPSS is a probabilistic model that estimates the likelihood that a CVE will be exploited in the next 30 days, based on observed exploitation data and vulnerability characteristics. EPSS scores are calculated by FIRST and updated daily.
EPSS is empirical where CVSS is theoretical. A CVE with a high EPSS score is being exploited now or is structurally similar to CVEs that are being exploited now. A CVE with a low EPSS score, regardless of its CVSS score, is not currently in active exploitation and is therefore lower priority.
Using CVSS and EPSS together provides both severity context (how bad is this CVE if exploited?) and exploitation probability context (how likely is this CVE to be exploited in the near term?). The highest-priority findings are high CVSS and high EPSS—severe and actively being exploited.
CISA KEV catalog membership
KEV membership is a binary high-priority signal. If a CVE is in the KEV, it’s confirmed to be actively exploited in the wild. Remediate KEV CVEs faster than CVSS score would suggest, regardless of the specific score.
Exposure context
A CVE in a package used by an internet-facing service with direct user input handling is higher priority than the same CVE in a package used by a backend batch processing service with no external network access. CVSS doesn’t differentiate; exposure context does.
Building a Better Prioritization Framework
The framework that replaces CVSS-only prioritization uses CVSS as one input among several:
Tier 1 (Immediate): CVEs in the CISA KEV catalog, or CVEs with EPSS > 0.5 (top 5% exploitation probability), in packages that execute at runtime.
Tier 2 (Within 30 days): CVEs with CVSS 9.0+ and EPSS > 0.1, in packages that execute at runtime, in internet-facing services.
Tier 3 (Within 90 days): CVEs with CVSS 7.0+ in packages that execute at runtime, not in Tier 1 or 2.
Tier 4 (Address through standard maintenance): CVEs in packages that execute at runtime but with CVSS < 7.0 and low EPSS scores.
Eliminated: CVEs in packages that don’t execute at runtime. These are removed from images through container security software hardening, not remediated through patching.
Practical Steps for the Transition
Measure how many of your current high-CVSS findings are in packages that don’t execute. Run a runtime profiling session against representative production containers and compare the profiling output to the CVE finding list. The percentage of findings in non-executing packages is the fraction of your current prioritization workload that a better framework eliminates.
Add EPSS data to your vulnerability management platform. CISA and FIRST publish EPSS data as downloadable feeds. Vulnerability management platforms that ingest EPSS can add it as a filter and sort dimension alongside CVSS.
Subscribe to KEV catalog updates. CISA provides the KEV catalog as a machine-readable feed. Integrating KEV membership as an automatic priority override—KEV entries jump to Tier 1 regardless of CVSS score—ensures rapid response to confirmed active exploitation.
Report prioritization framework performance. Track what percentage of remediated CVEs in each time period were in the top tiers. A prioritization framework that successfully routes high-EPSS, runtime-executing CVEs to the front of the queue should show those CVEs being remediated faster.
Frequently Asked Questions
Why do CVSS scores fail at vulnerability prioritization in practice?
CVSS scores fail at vulnerability prioritization because they measure theoretical severity in a generic context, not actual risk in a specific environment. A CVSS 9.8 score doesn’t account for whether the vulnerable function is called in your application, whether the package executes at all in your container, or whether active exploitation is occurring. In container environments with hundreds of high-CVSS findings per image, CVSS-only prioritization produces finding lists that exceed available remediation capacity, with no distinction between CVEs in actively-used packages and CVEs in packages the application never touches.
What should be used instead of CVSS scores for vulnerability prioritization?
Effective vulnerability prioritization combines three signals that CVSS lacks: runtime execution context (does the vulnerable package actually execute in this container?), EPSS score (what is the current probability of exploitation in the next 30 days?), and CISA KEV membership (is this CVE confirmed as actively exploited?). Runtime context is the most powerful filter—packages that don’t execute cannot be exploited, regardless of CVSS score, and should be removed rather than prioritized. EPSS and KEV together identify which remaining CVEs represent genuine near-term risk.
How does CVSS affect vulnerability prioritization workflows?
When CVSS is the sole prioritization signal, teams spend significant effort triaging vulnerabilities in packages that never execute in their production environment. For a typical container fleet with general-purpose base images, 75-90% of installed packages don’t execute during application operation, yet CVSS-only workflows assign triage effort to all their CVEs. Adding runtime execution context as a filter before CVSS-based ranking eliminates this wasted effort and focuses the prioritization queue on the CVEs that represent actual exploitable exposure.
What is the EPSS score and how does it improve on CVSS for prioritization?
EPSS (Exploit Prediction Scoring System) estimates the probability that a specific CVE will be exploited in the next 30 days, updated daily by FIRST based on real-world exploitation data. Where CVSS reflects theoretical severity assigned at disclosure and rarely updated, EPSS reflects current exploitation reality—a CVE being actively used in attacks today has a high EPSS score even if its CVSS score is moderate. Using CVSS and EPSS together provides both a severity ceiling and a real-time exploitation probability, producing prioritization decisions that reflect current threat conditions.
The Goal of Prioritization
CVSS is useful for understanding vulnerability severity in a generic context. It’s not useful for deciding what to work on first in your specific environment. A prioritization framework that incorporates runtime execution context, exploitation probability, and known active exploitation produces finding lists where the highest-priority items are the ones most likely to cause actual harm to your specific environment—which is the only prioritization that matters.