A scanner that returns forty percent of its findings as High or Critical has not discovered that forty percent of your infrastructure sits one exploit away from compromise. It has revealed that CVSS, as a scoring system, clusters at the top of its own scale far more often than real-world exploitation clusters at the top of yours. Hand that list to a patch team in score order and the result is not risk reduction. It is a coin flip wearing a project plan.
This is not an argument against CVSS. The score is well-defined, widely implemented, and required by more than one compliance framework. The argument is narrower: CVSS answers a specific technical question, and teams keep asking it a different one. Knowing exactly where that mismatch comes from is what lets you keep CVSS in the pipeline without letting it run the pipeline.
The Arithmetic Problem: What a Critical-Heavy Queue Actually Tells You
Run an unauthenticated scan across a mid-size estate with an old patch cadence and it is common to see a third or more of findings land in High or Critical. That is not a queue, it is a backlog with a label on it. A prioritization list has to be short enough that a team can act on the top of it this week. A list where a third of everything qualifies as top priority is a list that has stopped prioritizing.
The cause is structural. CVSS Base scores are computed from the vulnerability’s own characteristics in isolation: how it is reached, how complex the attack is, what privileges it needs, and what it can do to confidentiality, integrity, and availability if triggered. None of those inputs know whether the affected service is internet-facing or sits behind a compensating control. Two findings with identical Base scores can carry very different real risk, and CVSS by design cannot tell them apart. The scanner is not wrong, it is answering a different question than “what should I fix first.”
Severity Is Not Risk: What CVSS Actually Measures
The CVSS Base metric group covers eight values: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the Confidentiality, Integrity, and Availability impact triad. Every one of them describes the vulnerability itself, not the environment it sits in and not the world’s interest in abusing it. A 9.8 on software nobody has bothered to write an exploit for and a 9.8 on a mass-exploited edge device carry the same number, because the number was never meant to encode exploitation activity.
CVSS does define two additional metric groups built to close this gap: Temporal, which accounts for exploit code maturity and remediation level, and Environmental, which lets an organization adjust for its own exposure and controls. In practice almost nobody scores or ingests these. Most feeds and most tickets carry only the Base score, because Temporal and Environmental require manual input that most tooling never asks for. So the part of CVSS designed to bring in context is the part that gets dropped, and pure technical severity ends up running the show alone.
Four Documented Failure Modes in CVSS-Driven Prioritization
Score inflation toward the top of the scale
Vendors and researchers scoring a disclosure have an incentive to round up: understating severity looks bad if the flaw turns out worse than reported, and overstating it carries little downside. The result is a scale that behaves less like a spread and more like a cliff, with entries clustered in the 7.0-plus band, so the score stops discriminating between findings that need attention this week and findings that can wait a quarter.
Missing context by design
Because the number reaching your ticketing system is almost always the Base score alone, it cannot express whether a vulnerable service is reachable from the internet, sits behind a WAF, requires an already authenticated session, or protects a system holding no sensitive data. Two organizations running the same vulnerable package inherit the same score and can carry opposite actual risk.
Static scores in a system where exploitability changes weekly
A CVSS Base score is assigned once, near disclosure, and almost never revisited. But the facts that determine real risk keep moving: a proof-of-concept goes public, an exploit module ships, scanning activity spikes, or a vendor patch quietly removes the exposure. None of that updates the number in your vulnerability database, so a finding scored 7.5 on day one and mass-exploited on day ninety still shows 7.5, several rows below a Critical nobody has ever weaponized.
Vendor and NVD inconsistency for the same CVE
It is routine for the National Vulnerability Database, a vendor’s own advisory, and a Linux distribution’s security team to publish three different scores for the same CVE, because each scores a different deployment assumption or interprets Scope and Attack Complexity differently. A team ingesting feeds from more than one source without reconciling them will see the same flaw land at different severities depending on which feed populated the ticket.
The Counter-Evidence: Most Critical-Rated CVEs Are Never Weaponized
CISA maintains the Known Exploited Vulnerabilities catalog specifically because the population of CVEs with confirmed, in-the-wild exploitation is a small, trackable subset of all published CVEs, not the majority of them. If severity alone predicted exploitation, the KEV list and the Critical-severity list would be close in size. They are not. Most Critical and High findings in any given database will never appear in an incident report, while some Medium-severity findings, particularly ones with low attack complexity and no authentication requirement, get mass-exploited within days of disclosure.
This is the gap the Exploit Prediction Scoring System, published by FIRST.org, was built to close. EPSS estimates the probability that a given CVE will be exploited in the next thirty days, based on observed scanning and exploitation activity, and it is deliberately independent of CVSS. A vulnerability can carry a 9.8 CVSS score and a near-zero EPSS probability, or a 6.5 CVSS score and an EPSS probability above 0.5. Many teams treat an EPSS probability above roughly 0.1, a one-in-ten chance of exploitation within a month, as a trigger for expedited handling regardless of the CVSS field, because that threshold tracks real exploitation far better than severity alone.
What CVSS Is Actually Good For
None of this makes CVSS worthless. It remains the only severity language every scanner, vendor advisory, and compliance framework speaks in common, which makes it indispensable as a baseline rather than as a sort key. PCI DSS Requirement 11.3.1.1 sets remediation obligations by CVSS band, and SOC 2 and ISO 27001 assessors expect a documented severity taxonomy mapped to a recognized standard. Dropping CVSS from the process entirely means losing that shared vocabulary and the audit trail it produces.
CVSS is also reliable at the one thing it was built for: comparing the technical severity of two vulnerabilities in the abstract. It is a legitimate floor filter, a way to say that a Low-severity, locally exploitable finding on a workstation with no privileged access does not warrant emergency handling, whatever the finding’s title suggests. Used to remove noise from the bottom, CVSS earns its place. Used as the only sort key at the top, it produces exactly the flat, undifferentiated Critical pile described earlier.
A Replacement Decision Chain: Severity as One Input Among Several
The fix is not a better severity score. It is a decision chain that treats CVSS as the first filter and adds the variables CVSS was never built to carry: documented exploitation, exposure, and asset value. A workable version runs in this order:
- CVSS as a floor, not a sort. Use the Base score to exclude findings below a threshold set per asset tier, for example ignoring Low-severity findings on non-critical, non-internet-facing assets, rather than to rank the survivors.
- Exploitation evidence. Check the finding against the CISA KEV catalog and, where available, its EPSS probability. A KEV listing or an EPSS score above your chosen threshold overrides CVSS band and forces expedited handling.
- Exposure. Determine whether the affected asset is reachable from outside the perimeter, sits behind a compensating control, or needs an already authenticated session to reach. This is the variable most CVSS-only processes never check per finding.
- Asset value. Weight the result by what the asset holds or does: a domain controller or a system storing regulated data outranks a disposable test instance carrying the identical CVE.
The table below shows four findings with the information a triage queue would normally receive, and how the resulting priority diverges from a CVSS-only sort.
| Finding | CVSS Base | Exploitation evidence | Exposure | Asset tier | Resulting priority |
|---|---|---|---|---|---|
| Finding A | 9.8 Critical | No KEV, EPSS 0.02 | Internal only | Tier 3, non-critical | Scheduled patch cycle |
| Finding B | 6.5 Medium | KEV listed, EPSS 0.87 | Internet-facing | Tier 1, crown jewel | Emergency, 24 to 48 hours |
| Finding C | 7.5 High | No KEV, EPSS 0.05 | Internet-facing | Tier 2 | Next patch window |
| Finding D | 9.1 Critical | KEV listed, EPSS 0.65 | Internal, segmented | Tier 1 | Expedited, 7 days with control review |
Finding B, a Medium-severity score, outranks two Critical findings once exploitation evidence and exposure are added, while Finding A, the highest Base score of the four, drops to routine scheduling once neither exploitation nor exposure supports urgency. That reordering is the point: it recovers the cases a CVSS-only sort buries and demotes the cases it inflates.
Building the chain into a repeatable workflow
Doing this by hand does not scale past a few hundred open findings, which is why the four steps map onto pipeline stages rather than a one-time spreadsheet exercise. Findings need deduplication and validation before scoring logic runs, so the same flaw reported by three scanners is not scored three times. Platforms that automate this recombination, such as SITEY, fold the CVSS Base score, exploit prediction data, and asset context together during a dedicated Risk Scoring phase that runs after AI validation and triage confirms a finding is real, rather than asking an analyst to reconcile four spreadsheets for every new CVE.
The exposure variable depends on knowing, continuously, what is actually reachable from outside the perimeter rather than what a network diagram from eighteen months ago claims. That is a moving target as cloud instances spin up and DNS records change, which is why exposure needs to be sourced from live attack surface management data rather than a static spreadsheet. Asset value carries the same requirement: tiering has to come from a maintained asset inventory that tags crown-jewel systems and regulated data stores, not from institutional memory about which server matters.
Finally, whatever priority the decision chain produces is only as trustworthy as the verification that follows the fix. A ticket closed because a command returned exit code zero is not evidence the vulnerability is gone, particularly for configuration-based findings where the fix is a settings change that can silently fail or get reverted later. This is why retest matters more than ticket status: automated retest and closure workflows that re-scan the specific finding, rather than trusting the patch command’s own report of success, are what actually confirms the decision chain’s output was correct.
None of the four inputs requires exotic tooling. KEV is a free, public list. EPSS scores are published daily by FIRST.org at no cost. Exposure and asset tiering are the harder half, because they require a current inventory rather than a one-time scoring feed, and that inventory work is exactly what most teams skip when they fall back on sorting by CVSS alone. The severity score was never the missing piece. The missing piece was always the three inputs sitting next to it.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.