CVSS Scores Aren't Enough: Why Contextual RBVM Beats CVSS, EPSS & CISA KEV

For most of the last decade, the consensus answer to "how should I prioritise vulnerabilities?" has been some combination of CVSS, EPSS, and CISA KEV. CVSS for technical severity. EPSS for exploitation probability. KEV for confirmation of in-the-wild use. Stack the three, and you have an industry-standard prioritisation pipeline.

That pipeline is a real improvement over CVSS alone. But it has a structural blind spot: every input describes the vulnerability at internet scale, not in your environment. CVSS is the same number on every host. EPSS is the same probability for every organisation. CISA KEV is a binary that doesn\'t care whether you run the vulnerable software or whether your team can remediate quickly. None of these signals tell you what attacking you would actually look like, or what risk a given finding actually poses to your specific operations.

That gap is the entire reason Centraleyezer scores risk differently. Real RBVM is not "CVSS plus two more internet feeds." Real RBVM is contextual: a score that is built from the finding, the asset it lives on, the network around the asset, the threat landscape relevant to you, and the team that has to fix it. That is what this post is about.

CVSS — the Common Vulnerability Scoring System — was never designed as a prioritisation engine. It was designed as a technical-severity rubric for a CVE in the abstract: how bad is the bug itself, on a scale of 0 to 10, on a hypothetical fully-exposed system with no mitigations? That is a useful question, but it is not the question security teams actually need answered. The question they need answered is: given my assets, my network, and my team — which of these findings will cause an incident first?

Most organisations end up running a CVSS-driven queue anyway because nothing else is standardised. The result is a queue that systematically buries moderate-CVSS findings on critical assets and floats high-CVSS findings on irrelevant ones. CVSS is not the wrong number; it is the wrong question for prioritisation.

The standard answer to "CVSS isn\'t enough" has been to layer on EPSS — the Exploit Prediction Scoring System from FIRST.org, which gives a 0–1 probability that a CVE will be exploited in the wild within 30 days — and to overlay CISA KEV, which flags CVEs confirmed exploited somewhere on the internet. That stack is an improvement over CVSS alone. It is still not contextual.

Here is the difference in plain terms:

• CVSS answers "how technically severe is this CVE in the abstract?" Useful for risk-comms; useless for triage on its own.
• EPSS answers "across the entire internet, what is the probability someone exploits this CVE in the next 30 days?" Useful as a tiebreaker; uninformative about your specific exposure.
• CISA KEV answers "has this CVE been confirmed exploited somewhere in the wild?" Useful as evidence; uninformative about whether you are exposed.
• Contextual risk scoring answers "given this finding, on this asset, in this network, with this team, against this threat landscape — how risky is it for me?" That is the question that decides the queue.

CVSS, EPSS, and KEV are still ingested in Centraleyezer for traceability — auditors love them, and they are useful in the technical report — but they are deliberately not used as inputs to the contextual score. The score is built from six factors that do describe your environment.

These three signals are useful, well-designed, and freely available. They are also all measuring the same kind of thing — properties of a CVE in the abstract. None of them know anything about your assets, your network topology, your threat landscape, or your team\'s response patterns. A complete prioritisation system has to add the things they can\'t see.

• CVSS describes technical severity in a vacuum — a 9.8 on a wide-open production database scores identically to a 9.8 on an air-gapped lab machine.
• EPSS describes the probability that someone, somewhere will exploit a CVE in the next 30 days — not whether anyone is targeting your sector, your stack, or your perimeter.
• CISA KEV confirms that a CVE has been exploited in the wild somewhere — but a "KEV-yes" finding on a network you don't expose may be far less risky than a "KEV-no" finding on your customer-facing API.
• None of the three account for whether your team will actually fix the issue this week or this quarter — yet that gap is one of the largest determinants of real-world exposure.

The result, in any organisation that runs CVSS-or-EPSS-driven triage at scale, is the same: a queue that systematically over-prioritises high-severity findings on low-impact assets and systematically under-prioritises moderate-severity findings on the assets that matter most. Audit-ready, but operationally wrong.

Centraleyezer\'s contextual risk score for every vulnerability–asset pair is built from six factors. Each one answers a question that CVSS, EPSS, and KEV cannot answer on their own.

The first five factors describe the finding and the asset. The sixth describes the people. That is the factor no internet-wide signal will ever provide — and the one that most accurately predicts whether a vulnerability will turn into an incident.

A "high" finding owned by a team that historically remediates in 48 hours is operationally much less dangerous than a "medium" finding owned by a team that historically takes six weeks. The exposure window is what attackers exploit. CVSS, EPSS, and KEV are blind to it. The Human-AI loop is not.

In practice, this means the same finding on the same asset can receive a different contextual score across two organisations — or even two teams in the same organisation — depending on their actual response patterns. Security leaders get a far more honest picture of where their real risk concentrates: not on the vulnerabilities that score highest in the abstract, but on the ones that will live unfixed the longest in their reality.

Teams that move from CVSS-driven (or CVSS+EPSS-driven) triage to a contextual model consistently see four shifts in operations within the first quarter:

• The "critical" queue shrinks dramatically. The findings that remain are the ones that actually warrant emergency response.
• The "medium" queue starts producing real surprises — the findings on critical assets owned by slow teams now show up where they always belonged: at the top.
• Risk acceptance becomes meaningful. When a finding is contextually low, accepting it is a defensible decision, not a quiet capitulation.
• Conversations with auditors get easier. "Why didn't you patch this 9.8?" has a real answer when the score reflects exposure, asset criticality, and compensating controls — not raw severity.

This is what we mean when we say Centraleyezer prioritises by actual business risk rather than raw severity. CVSS, EPSS, and CISA KEV remain useful as ingestion metadata and for traceability — your CVE records carry them, your technical reports show them, your auditors can see them — but they are not what drives the prioritisation. The contextual score does.