Why severity scores cannot be used to decide which vulnerability to fix

Severity scores leave the remediation order unresolved

An illustrative dependency scan of a moderately sized JavaScript project can leave an engineer with 10, 20, sometimes 50 findings carrying similar labels such as “high.” The engineer then has to decide where to spend the next hour. Sorting by severity gives an immediate work order, but that order leaves out evidence needed to choose the most urgent task.

The gap arises because a severity score describes potential technical harm, while a remediation decision depends on the affected application. Common Vulnerability Scoring System (CVSS) scores help explain how serious exploitation could be. Engineering priority also depends on whether the vulnerable code runs in production, whether an attacker can reach it, and whether exploitation is likely or already occurring. A medium-severity finding can therefore deserve attention before a more severe one.

To make that decision, security teams already combine severity with threat intelligence, exploit catalogs, asset information, and vendor-specific risk models. Developer-facing scanners can leave much of that context out, showing an advisory identifier and severity label instead. Engineers must then follow the score, reconstruct the context, or seek other evidence. An exploitation forecast can focus that investigation if its meaning and limits stay visible.

Severity, forecasts, and observed exploitation answer different questions

CVSS describes a vulnerability’s technical characteristics and potential consequences in a structured way. Its Base metrics cover attack vector, attack complexity, required privileges, user interaction, and possible effects on confidentiality, integrity, and availability. A high Base score indicates severe potential harm under the conditions those metrics describe. Engineers can use those conditions as a starting point for assessing impact.

Applying that assessment to a deployment requires more evidence because the Base score does not describe the application around the vulnerability. Engineers still need to establish whether the vulnerable function is reachable, whether the system faces the internet, and whether protective measures reduce exposure. Current exploitation is a separate question. Remediation priority depends on combining these answers with severity.

The Exploit Prediction Scoring System (EPSS), maintained by FIRST and updated daily, adds evidence about likely exploitation. For a published Common Vulnerabilities and Exposures identifier, or CVE, it estimates the probability that exploitation activity will be observed in the wild over the next 30 days. The forecast covers activity involving that vulnerability across the wider environment. A particular application’s chance of compromise also depends on its exposure and defenses.

Reading the forecast correctly means distinguishing probability from percentile. EPSS probability is the model’s direct estimate; percentile shows where that estimate ranks among scored CVEs. As an illustrative example, a finding at the 93rd percentile ranks above 93% of scored CVEs and falls within the highest-ranked 7%. A 90th-percentile finding can still have an absolute forecast of only a few percent because exploitation has a low base rate; its percentile does not imply a 90% probability.

Because severity and exploitation probability measure different things, CVSS and EPSS can point in different directions. A vulnerability with severe potential consequences can have a low near-term forecast, while a medium-severity vulnerability can rank highly in EPSS. Showing both preserves two separate reasons to investigate. Neither number supplies the deployment evidence needed to finish the decision.

Observed exploitation adds another kind of evidence. The Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog, commonly called CISA KEV, and reliable threat intelligence can establish that exploitation has occurred. EPSS remains a forecast, so it cannot establish an active campaign or application reachability. Application and asset information must establish whether the affected code is present, reachable, and consequential in the environment under review.

Investigation lanes make the signals easier to use

One way to present these signals together is CVE Lite CLI’s four-lane classification. The developer, who benefits from adoption of the tool, uses severity and EPSS percentile to suggest what engineers should investigate next. The product treats a forecast at or above the 90th percentile, the highest-ranked 10% of CVEs, as elevated. FIRST does not prescribe that boundary as a universal policy; the developer chose it to keep the elevated investigation queue manageable.

Using that boundary, the tool assigns findings to the following lanes. Each label suggests an investigation priority whose urgency can change with local evidence. Even Fix Now needs interpretation before a team turns it into a deadline or release rule.

These lanes preserve distinctions that a severity-only queue hides. Fix Soon retains the significance of a technically severe vulnerability, while Monitor draws attention to a less severe issue with an elevated forecast. Lower Priority still carries a remediation obligation. Teams can adjust their policy to reflect remediation capacity, exposure, and risk tolerance.

Local evidence can also change the order between lanes. A reachable Monitor finding in an internet-facing authentication service may deserve attention before a Fix Soon finding in an unused development tool. The authentication service adds exposure and consequences that the two scores cannot express. So the interface needs to show the severity and forecast behind each category and allow reachability, asset importance, or confirmed exploitation to change the decision.

The developer’s case study using the Lit repository shows why preserving both signals matters. Its scan found a critical form-data vulnerability associated with CVE-2025-7783 and a medium-severity Karma finding associated with CVE-2022-0437. In the case study’s undated EPSS snapshot, form-data ranked around the 77th percentile and Karma above the 96th percentile. Those values belong to that snapshot; EPSS rankings change as the model is refreshed.

Under the lane rules, form-data entered Fix Soon and Karma entered Monitor. The critical finding retained attention because of its potential impact, while the medium-severity finding gained visibility because of its high relative exploitation forecast. A severity-only display would place Karma well below form-data and could encourage an engineer to leave it unattended. The combined view gives the engineer a reason to investigate both before deciding which remediation comes first.

Choosing between them requires examining the affected application. The engineer needs to determine whether each package sits on a production execution path, whether execution can reach the vulnerable function, and how exposed the system is. The consequences of exploitation and any confirmation from CISA or other trusted threat intelligence can further change urgency. Until those checks are complete, the open questions need to stay visible alongside the lane.

Vulnerability prioritization needs deployment evidence

The deployment questions raised by the Lit findings are the focus of CAPE, the Context-Aware Prioritization Engine. Colorado State University researchers Rakesh Podder, Viktoria Koscinski, and Indrajit Ray developed the framework to bring deployment-specific evidence into vulnerability prioritization. CVE Lite CLI’s developer collaborates with the CSU team, connecting this research to the product’s development plans. The collaboration brings together approaches with different roles: forecast-based grouping and analysis of an application’s conditions.

CAPE begins by adding reachability, centrality, and exploitability analysis for the deployment to each CVE. Reachability examines whether execution can reach affected code, while centrality assesses the importance of an affected component within the structure being analyzed. The framework then uses the Analytic Hierarchy Process (AHP), a method for combining decision criteria, to calculate a ranked priority score. Deployment characteristics therefore become ranking inputs alongside information about the vulnerability.

To evaluate the approach, the CSU team examined 30 open-source projects containing over 6,000 scanner-reported CVEs. They reported that 43.3% of those findings were statically unreachable: analysis performed without running the software identified no execution path to the affected code. The reported shares were 53.1% for TypeScript and JavaScript and 27.4% for Python. The highest share in an individual project was 76.1%.

These percentages describe scanner findings within the evaluated projects, so their practical meaning concerns how a finding relates to the analyzed code. A substantial share had a deployment characteristic that severity and exploitation forecasts cannot establish. The measurement concerns findings rather than developers, teams, or organizations. It shows why a useful forecast about a CVE still leaves work to determine that CVE’s relevance to a particular application.

Interpreting static unreachability requires the same attention to deployment conditions. The result describes the code and conditions analyzed, and those conditions can change as software and its use evolve. Reachability analysis therefore helps engineers decide where to investigate and allocate effort. Treating every unreachable finding as permanently safe would extend the result beyond the conditions it describes.

This deployment evidence serves a different purpose from the Lit case’s illustration of score visibility. CAPE examines application relevance across projects, while the Lit findings show why severity and forecast should stay visible together. CVE Lite CLI’s developer is exploring contextual signals with the CSU team, including reachability and the distribution of remediation effort. Using those signals in deployment-informed scoring remains exploratory work, separate from the implemented EPSS classification.

Put the explanation where dependency decisions happen

The implemented classification already brings forecast information into an engineer’s working queue. According to CVE Lite CLI’s developer, version v1.33.0 introduced the four-lane model as EPSS Priority Signal. When an advisory has multiple CVE aliases, different identifiers associated with the same advisory, the tool retrieves their available EPSS percentiles and uses the highest value. The developer’s rationale is to prevent a lower-scoring alias from hiding a stronger forecast linked to that advisory.

The developer says the selected signal appears in the verbose terminal table, the HTML report, and the JSON field prioritySignal. Those locations matter because an engineer reviewing an illustrative queue of 20 findings may never use a forecast buried in a machine-readable response. Terminal output makes it available during inspection, while carrying it into remediation planning and continuous integration (CI), the automated checks run as code changes are integrated, lets teams use it in policy. The explanation needs to travel with the category so another engineer can understand the assignment.

That explanation is especially useful during local scans and CI runs because engineers can still act on dependency choices at those points. They can investigate while deciding whether to update, replace, or retain a dependency. Weekly dashboards support governance and oversight at a different stage. Evidence available during the code decision can directly inform the dependency choice.

Turning that evidence into release policy requires keeping independent reasons for urgency separate. A team may make Fix Now one blocking condition and also stop a release because of a CISA KEV match, confirmed reachability, or a critical production asset. Monitor and Lower Priority findings can enter tracking unless local conditions raise their urgency. Teams can also allow a release containing a Fix Now finding when their policy and application evidence justify that decision.

A gate built this way can explain more than a blanket rule that stops delivery for every high-severity advisory. CVE Lite CLI’s developer warns that persistent gate noise encourages eventual bypass. A useful gate identifies why it elevated the finding, which questions remain open, and what evidence can override the default. Engineers can then evaluate the decision and record a reasoned exception when appropriate.

Keep missing forecasts visible as unresolved evidence

Release policy also needs to handle a newly discovered high-severity or critical CVE that has neither EPSS information nor a CISA KEV record. Its potential impact is already significant, but its exploitation forecast and confirmed-exploitation status remain unresolved. An absent forecast cannot be treated as a low forecast. Likewise, absence from KEV leaves open the possibility of exploitation.

Because the four lanes depend on a forecast, their conditions alone cannot place this finding in a defensible category. The team must examine the affected application and asset, including production use, reachability, exposure, and likely consequences. Those checks can justify urgent action while the forecast remains unavailable. The working queue should retain the missing-forecast state and record the evidence behind the chosen action, rather than silently assigning the finding a lower-priority lane.

Key executive takeaways

• Prioritize with deployment evidence: Security and engineering teams need severity, exploitation intelligence, and application exposure to set remediation order. A reachable medium-severity vulnerability can warrant attention before a critical finding in unused code.
• Keep risk signals distinct: CVSS describes potential technical harm, EPSS forecasts observed exploitation, and CISA KEV records known exploitation. Security teams need to preserve these distinctions, including the difference between an EPSS probability and its percentile ranking.
• Use lanes to direct investigation: Priority lanes help engineers organize findings while keeping severity and exploitation forecasts visible. Security owners need to define thresholds around remediation capacity, exposure, and risk tolerance, with local evidence able to change the order.
• Validate application reachability: CAPE researchers reported that 43.3% of scanner findings across 30 evaluated projects were statically unreachable. Engineering teams can use reachability analysis to focus investigation, while reassessing results as code and deployment conditions change.
• Explain release decisions: Platform teams that own CI pipelines need to carry prioritization signals and their rationale into release gates. Explicit blocking conditions and documented exceptions make decisions easier to review and reduce pressure to bypass noisy checks.
• Preserve uncertainty: Missing EPSS data and absence from CISA KEV leave exploitation questions unresolved. Security and application owners need to assess reachability, production exposure, and potential consequences, then record the evidence behind the chosen action.