Beacon compared with CVSS, EPSS, KEV and SSVC

These systems are frequently presented as alternatives. They are not. Each answers a different question, and the confusion between them is a substantial part of why vulnerability programmes struggle.

The short version: CVSS scores severity, EPSS predicts exploitation, KEV confirms it, SSVC decides whether to act, and Beacon assigns the organisational response — a tier, a deadline, an owner, and an escalation path. Beacon consumes the others as inputs.

At a glance

What each system covers

The gaps are not defects. Each system was scoped deliberately — the problem is using one to do another's job.

Capability comparison of Beacon Standards, CVSS, EPSS, CISA KEV and SSVC
Capability	Beacon	CVSS	EPSS	KEV	SSVC
Covers software vulnerabilities	● yes	● yes	● yes	● yes	● yes
Covers misconfigurations	● yes	○ no	○ no	○ no	◐ partial
Covers identity and access weaknesses	● yes	○ no	○ no	○ no	○ no
Covers process and governance gaps	● yes	○ no	○ no	○ no	○ no
Accounts for reachability in your environment	● yes	◐ partial	○ no	○ no	● yes
Accounts for observed exploitation	● yes	○ no	● yes	● yes	● yes
Accounts for compliance obligation	● yes	○ no	○ no	○ no	○ no
Produces a remediation deadline	● yes	○ no	○ no	◐ partial	◐ partial
Names an owner and escalation path	● yes	○ no	○ no	○ no	○ no
Provides stable finding identifiers	● yes	○ no	○ no	○ no	○ no

● full · ◐ partial · ○ not covered

In detail

Each system on its own terms

Written to be fair to each. Every one of these is well-designed for the problem it was built to solve.

CVSS

FIRST

Common Vulnerability Scoring System

Answers: How severe is this vulnerability in the abstract?
Output: A 0.0–10.0 score
Scope: Software vulnerabilities with a CVE

What it does well

Universally understood, vendor-independent, and present in essentially every scanner's output. The base score is a genuinely useful shorthand for intrinsic severity, and the temporal and environmental metrics — which almost nobody uses — were designed to address exactly the contextual gap people complain about.

Where it stops

The base score describes the vulnerability, not your exposure to it. It cannot express whether the component is reachable, whether anyone is exploiting it, or what data sits behind it. Because most organisations use base scores alone, prioritising by CVSS means prioritising by a number that is identical for every organisation on earth.

Using it with Beacon

Beacon uses CVSS as one input to question 2. A high score raises the likelihood that exploitation grants meaningful access, but it never determines the tier by itself.

Official documentation

EPSS

FIRST

Exploit Prediction Scoring System

Answers: How likely is this vulnerability to be exploited in the next 30 days?
Output: A probability between 0 and 1
Scope: Software vulnerabilities with a CVE

What it does well

A genuine advance over severity scoring. EPSS is empirically grounded, updated daily, and dramatically outperforms CVSS at the specific task of identifying which vulnerabilities will actually be attacked. For triaging a large CVE backlog it is the single most useful signal available.

Where it stops

It is a prediction, not a decision. EPSS tells you the probability of exploitation but nothing about consequence, reachability, compliance obligation, ownership, or deadline. A 0.4 probability on an isolated system and a 0.4 on a payment gateway are the same number and entirely different problems.

Using it with Beacon

Beacon consumes EPSS as an input to question 2 and as the ordering signal within the Tier 1 queue once tiers are assigned.

Official documentation

CISA KEV

CISA

Known Exploited Vulnerabilities Catalog

Answers: Is this vulnerability confirmed to be exploited in the wild?
Output: Binary — listed or not listed
Scope: Software vulnerabilities with confirmed exploitation

What it does well

Authoritative and unambiguous. KEV removes the guesswork from the hardest question in vulnerability management, and its narrowness is the point: a list that is a fraction of a percent of published CVEs is a list you can act on completely.

Where it stops

Deliberately narrow. KEV covers only software vulnerabilities with confirmed exploitation, which excludes misconfigurations, identity weaknesses, and process gaps — the majority of findings in a cloud estate. It is also necessarily lagging: a vulnerability enters KEV after exploitation is observed.

Using it with Beacon

KEV membership makes question 2 an automatic yes. Combined with reachability it places a finding in Tier 1 regardless of CVSS score — the case Beacon most wants to catch.

Official documentation

SSVC

Carnegie Mellon SEI

Stakeholder-Specific Vulnerability Categorization

Answers: Given my context, should I act on this vulnerability now?
Output: A decision: defer, scheduled, out-of-cycle, or immediate
Scope: Software vulnerabilities

What it does well

Methodologically the closest system to Beacon, and rigorous. SSVC's insight — that prioritisation is a decision problem rather than a scoring problem, and that the decision depends on who you are — is correct, and its decision trees are transparent and auditable in a way that scores are not.

Where it stops

Scoped to software vulnerabilities, so it does not classify the misconfiguration, identity, and process findings that dominate modern estates. Its output is also a decision rather than an operational commitment: it tells you to act out-of-cycle without naming an owner, a deadline, or an escalation path.

Using it with Beacon

Complementary, and the two compose cleanly. Organisations already running SSVC can treat its output as the input to Beacon questions 1 and 2, then use Beacon for the operational layer SSVC leaves open.

Official documentation

OWASP Risk Rating

OWASP

OWASP Risk Rating Methodology

Answers: What is the overall risk of this issue, combining likelihood and impact?
Output: A qualitative rating: note, low, medium, high, or critical
Scope: Application security findings

What it does well

Explicitly incorporates business impact and threat-agent factors, which pure severity scoring omits. It is well-suited to penetration test reporting, where an assessor has enough context to reason about a specific application.

Where it stops

Its factor estimates are subjective, so two assessors readily produce different ratings for the same finding — the problem Beacon's fixed question order is designed to eliminate. It is also application-scoped, with no natural home for infrastructure or identity findings.

Using it with Beacon

Useful for the impact reasoning inside question 2. Beacon then converts the rating into a tier with an attached SLA and owner.

Official documentation

In practice

How to run all of them together

None of this requires abandoning what you already use. The systems layer.

1
Ingest findings from every source
Scanners, cloud posture tools, penetration tests, and architecture reviews. Findings without a CVE are findings — most of your real exposure has no CVE at all.
2
Enrich CVE-bearing findings with CVSS, EPSS and KEV
These give you severity, predicted exploitation, and confirmed exploitation. They cover only the subset of findings that carry a CVE, which is why they cannot be the whole system.
3
Determine reachability from your own environment
This is the input none of the external systems can supply, and the one that most changes the answer. Network position and exposure data belong to you.
4
Apply the Beacon decision procedure
Four questions in order, producing a tier for every finding — including the misconfigurations and identity issues the other systems do not cover.
5
Route by domain, track against the tier SLA
The tier names the deadline and the escalation path; the domain names the team. This is the layer that converts analysis into completed work.

On the evidence for context over score

Successive volumes of the Cyentia/Kenna research found that roughly one in twenty published vulnerabilities is ever observed being exploited, and that remediating by CVSS score alone performs little better than remediating at random. This is the empirical basis for tiering on reachability and observed exploitation rather than on score.

Cyentia Institute — Prioritization to Prediction series →

The decision procedure Browse the catalog