Vulnerability prioritization: why a CVSS 9.8 can wait

A scanner flags a CVSS 9.8. The team drops everything, and two days later discovers the vulnerable component runs on an isolated test database that nobody outside the office can reach. Meanwhile a medium-severity flaw on an internet-facing login service, one that attackers are actively exploiting, waits in the backlog. That is the whole problem of vulnerability prioritization in one scenario: severity scores describe the flaw, not your exposure to it.

This guide sets out a practical order of questions that small engineering and security teams can apply every week, using two free, authoritative signals — CISA's Known Exploited Vulnerabilities catalog and FIRST's Exploit Prediction Scoring System — alongside the business context that no tool can supply.

Is CVSS enough to prioritize vulnerabilities?

No, and it was not designed to be. The Common Vulnerability Scoring System base score measures a vulnerability's intrinsic severity: attack vector, complexity, privileges required, and impact on confidentiality, integrity and availability. As a recent New Stack analysis puts it, a severity score is designed to be stable across environments, so it cannot tell a team whether an asset is exposed to the internet, shielded by compensating controls, or central to the business.

CVSS does include Threat and Environmental metrics that can add some of that context, but only if someone fills them in accurately and consistently. Most scanners report the base score, and most teams sort by it. The result is predictable: every finding above 9.0 looks equally urgent, and there are always more of them than hours in the week.

What is the CISA Known Exploited Vulnerabilities catalog?

The Known Exploited Vulnerabilities (KEV) catalog, maintained by the US Cybersecurity and Infrastructure Security Agency, lists vulnerabilities for which there is evidence of exploitation in the wild. It is the closest thing to a free, authoritative "this is being used by attackers now" list.

KEV is a strong signal precisely because it is narrow. It contains a small fraction of all published CVEs, and a match against a component you actually run deserves attention the same day. The limitation is equally clear: KEV tells you what has already been exploited. It says nothing about the flaw published last week that is about to be.

What is EPSS?

FIRST describes the Exploit Prediction Scoring System as a data-driven machine-learning model that estimates the probability a published CVE will be exploited in the wild in the next 30 days. It publishes a score between 0 and 1, with ranking percentiles, every day for every CVE, and makes the data freely available through CSV files and an API.

EPSS answers a different question from CVSS. CVSS asks "how bad would it be?"; EPSS asks "how likely is it to happen soon?". FIRST's own guidance is to combine EPSS with CVSS and KEV rather than use it alone, and to set thresholds deliberately rather than treat every non-zero score as urgent. Because scores change daily, a finding that was quiet last month can climb quickly when exploit code appears.

Which vulnerabilities should be fixed first?

Scores narrow the field. Business context decides the order. Jon Rose, founder of the advisory firm IOmergent, told The New Stack that the missing piece in every tool is "grounding in the business, the understanding of what actually matters". (IOmergent sells managed security, so read the framing as a practitioner's view with a commercial interest.) His questions, and ours, fall into four groups.

1. Is it reachable?

Can an attacker actually reach the vulnerable component? A library flagged in a service exposed to the public internet is a different problem from the same library in a batch job behind network controls, used by a handful of internal staff. Many findings, Rose notes, "get flagged, but it's not in a position where it could be triggered". Reachability analysis — from network exposure down to whether the vulnerable function is ever called — removes more noise than any score.

2. What does compromise touch?

An exposed flaw on a disposable test system may be a genuine security issue, but it does not carry the weight of the same flaw on the application that processes customer payments or stores personal data. Rank assets by consequence before you rank findings by severity. A simple three-tier asset list — revenue and customer data, internal operations, disposable — is enough to start.

3. Is it being exploited, or likely to be?

This is where KEV and EPSS earn their place. A KEV match on a reachable, high-consequence asset goes to the top. A high EPSS score raises a finding within its tier. A low EPSS score on an unreachable component is a strong candidate for scheduled rather than urgent work.

4. Where could it lead?

A modest flaw becomes urgent if it offers a path into privileged accounts, production systems or customer data. Conversely, a high-severity finding can be deprioritised — temporarily — if it is unreachable, limited in impact and protected by controls you have verified. Supply-chain and CI weaknesses are the classic case of a low-looking finding with a long attack path, as the RubyGems docs-builder attack and prompt injection against GitHub Actions secrets showed.

A worked example

Consider three hypothetical findings from one weekly scan. The first is a critical-severity flaw in a database driver used only by a test environment on a private network, with a low EPSS score and no KEV entry. The second is a high-severity flaw in the web framework behind your customer login page, and it appears in KEV. The third is a medium-severity flaw in an internal admin tool reachable over the company VPN, which would let an authenticated user escalate to administrator.

Sorted by CVSS, the order is one, two, three. Sorted by the four questions, it is two, three, one. The login flaw is reachable, touches customer accounts and is known to be exploited, so it is fixed today. The admin tool is internal but leads to privileged access, so it goes into this sprint. The test-database driver is scheduled, recorded as accepted risk with a review date, and re-checked if its EPSS score moves. Nothing was ignored; the order changed.

Vulnerability prioritization for small security teams

Rose says this approach is how teams get "thousands of alerts down to 10 to 20 prioritized tickets". You do not need a platform to start. A weekly routine that works for a team without a dedicated security function:

1. Keep an asset list with owners and tiers. Every service, its exposure (internet-facing or internal) and its consequence tier. This is the context scanners lack.
2. Enrich findings automatically. Join scanner output to KEV and the daily EPSS feed by CVE ID. Both are free; the join is a small script.
3. Sort by the four questions, not the score. KEV plus reachable plus high consequence first; high EPSS within each tier next; unreachable and low-consequence last.
4. Set fix windows by bucket. For example, days for the top bucket and the next scheduled release for the middle. Pick windows you can actually meet.
5. Record accepted risk. Anything deferred gets an owner, a reason and a review date. As Rose puts it, accepted risk is still risk; the difference is that it is explicit, time-bound and revisited.

Reachability often lives in the code, not the network diagram. An SBOM and a software composition analysis scanner tell you a vulnerable package is present; call-graph reachability, or simply checking whether the affected function is used, tells you whether it matters. Our write-up of the Forgejo template repository RCE is an example of tracing that path.

Why the window is shrinking

AI-assisted exploit development is shortening the gap between disclosure and exploitation, a trend we covered when GPT-6 Astra received the first Critical cybersecurity rating. That makes triage discipline more valuable, not less. When exploitation can follow disclosure within days, a team that spends its week on unreachable 9.8s has already lost the week.

The New Stack article also cites a study claiming that language models introduce far more vulnerabilities than developers. We have left that figure out: we could not verify it, and the argument here does not depend on it.

How to prioritize vulnerabilities beyond CVSS: a summary

• Use CVSS for severity, not for order.
• Treat a KEV match on a reachable, important asset as a same-day problem.
• Use EPSS to rank within a tier, and re-check it, because it changes daily.
• Maintain the asset context yourself; no scanner has it.
• Write down what you defer, and look at it again.

If your scanners produce more findings than your team can read, our QA and automation team can build the enrichment and triage pipeline into your CI, so the list engineers see each week is the short one.