Your scanner returned 4,000 findings. About 2,400 of them are rated High or Critical. Your team can remediate perhaps forty this month.
That arithmetic is the entire problem, and severity scoring alone does not solve it.
A CVSS score describes how bad a vulnerability would be if exploited. It says nothing about whether anyone will ever exploit it.
This guide covers the three data sources that actually answer that question, how they differ, and how to combine them into a rule your team can run on Monday.
Where this connects to your stack: CodeAnt AI correlates all three signals inside attack surface management, across more than thirty data sources including the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring. This article is the reasoning behind that correlation, written so you can apply it with any tooling.
What is vulnerability prioritization?
Vulnerability prioritization is the practice of ranking known vulnerabilities by the risk they pose to your specific environment, so that limited remediation capacity goes to the findings that matter.
It exists because two numbers never match. The number of vulnerabilities disclosed each year runs into the tens of thousands. The number any single team can fix runs into the hundreds.
The naive approach sorts by severity and works down the list. That fails for a structural reason worth stating plainly.
Severity is a property of the vulnerability. Risk is a property of the vulnerability in your environment, exposed to actual adversary behaviour. Sorting by severity alone optimises for the wrong variable.
Three public data sources give you the missing variables. Each answers a different question and none of them is sufficient alone.
Source | Question it answers | Maintained by |
|---|---|---|
CVSS | How bad would this be if exploited? | FIRST |
EPSS | How likely is exploitation in the near term? | FIRST |
CISA KEV | Is this being exploited right now? | CISA |
What is a CVSS score?
CVSS stands for the Common Vulnerability Scoring System. It is an open standard maintained by FIRST that produces a numeric severity rating from 0.0 to 10.0 for a given vulnerability.
The score is not a single opinion. It is computed from a defined set of metrics, which is what makes it comparable across vendors and researchers.
The CVSS severity ratings
Score | Rating |
|---|---|
0.0 | None |
0.1 to 3.9 | Low |
4.0 to 6.9 | Medium |
7.0 to 8.9 | High |
9.0 to 10.0 | Critical |
What the base metrics actually measure
The Base score, which is the number you almost always see quoted, is built from two groups.
Exploitability metrics describe how hard the vulnerability is to trigger. Attack Vector distinguishes network-reachable from physically-present. Attack Complexity captures whether conditions outside the attacker's control are required.
Privileges Required and User Interaction capture what the attacker must already have or must persuade someone to do.
Impact metrics describe what happens when it works, measured against confidentiality, integrity, and availability.
CVSS v4.0 restructured this. The old Scope metric was replaced by separate impact metrics for the vulnerable system and for subsequent systems, and the Temporal group was renamed Threat.
Many tools still report v3.1, so check which version a score refers to before comparing two numbers.
What a CVSS score does not tell you
This is where teams go wrong, so it is worth being blunt about the limits.
A Base score deliberately excludes your environment. It does not know whether the affected component is deployed, reachable from the internet, or behind three other controls.
It also excludes adversary behaviour entirely. A theoretically devastating flaw in software nobody attacks scores identically to one under active mass exploitation.
CVSS provides Temporal and Environmental metric groups precisely to address this. They go largely unused, because populating them requires per-asset work at a scale few teams can sustain.
The result is a well-known distribution problem.
A large share of all published CVEs score 7.0 or above, so "fix everything High and Critical" is not a prioritization strategy. It is a restatement of the backlog.
What is EPSS?
EPSS stands for the Exploit Prediction Scoring System. It is maintained by FIRST and it answers a completely different question from CVSS.
An EPSS score is a probability between 0 and 1 that a given CVE will be exploited in the wild within the next thirty days. Scores are recomputed daily.
How EPSS works
EPSS is a machine learning model trained on observed exploitation data.
It ingests features associated with each CVE, including vulnerability characteristics, the existence of public exploit code, references, vendor, and observed activity, and outputs a probability.
Two numbers are published per CVE and they are frequently confused.
The probability is the direct model output. A score of 0.10 means roughly a ten percent chance of observed exploitation in the next thirty days.
The percentile is where that CVE ranks against all others. A percentile of 0.95 means the CVE scores higher than ninety-five percent of all scored CVEs.
Use the probability for absolute decisions and the percentile for relative ranking. Reporting a percentile as if it were a probability is a common and consequential error.
Why EPSS changes the arithmetic
The base rate of exploitation is low. Only a small fraction of published CVEs are ever observed being exploited in the wild.
That means severity-first prioritization spends most of its effort on vulnerabilities nobody will ever attack.
EPSS is the correction, because it lets you exclude the large low-probability mass and concentrate on the tail.
The critical caveat is that EPSS is a prediction, not an observation.
A low score is not a guarantee of safety, and a targeted attack against your organisation specifically is exactly the case a population-level model handles worst.
What is the CISA KEV catalog?
The CISA Known Exploited Vulnerabilities catalog is a list of vulnerabilities with reliable evidence of active exploitation in the wild.
It is maintained by the United States Cybersecurity and Infrastructure Security Agency.
Note the disambiguation, because it costs people time. In this context KEV means Known Exploited Vulnerabilities. It is unrelated to any other use of those three letters.
The inclusion criteria
A vulnerability enters the catalog only when three conditions are met.
It has an assigned CVE ID. There is reliable evidence of active exploitation in the wild. And there is a clear remediation action available, typically a vendor patch.
That third criterion matters. The catalog is designed to be actionable, so a vulnerability with no available fix generally does not appear.
Why KEV outranks both other signals
CVSS is theoretical. EPSS is predictive. CISA KEV is observational.
If a CVE is in the catalog, the question of whether anyone exploits it has been answered empirically. No probability estimate improves on a confirmed observation.
The catalog also carries regulatory weight.
Under Binding Operational Directive 22-01, United States federal civilian executive branch agencies are required to remediate catalogued vulnerabilities by specified due dates.
Many private organisations have adopted the same standard voluntarily, because it is the clearest available definition of "urgent".
The limitation is coverage. The catalog contains only what CISA has confirmed, which means it is authoritative when a CVE appears and silent rather than reassuring when one does not.
How CVSS, EPSS, and CISA KEV compare
Dimension | CVSS | EPSS | CISA KEV |
|---|---|---|---|
Question | How bad if exploited? | How likely to be exploited? | Is it exploited? |
Output | 0.0 to 10.0 severity | 0 to 1 probability | Binary, in or out |
Nature | Deterministic formula | Statistical prediction | Empirical observation |
Update cadence | On publication or revision | Daily | As confirmed |
Environment-aware | Only via unused optional metrics | No | No |
Coverage | Nearly all CVEs | Nearly all CVEs | Small confirmed subset |
Best use | Sizing consequence | Excluding the improbable mass | Defining urgent |
Failure mode | Treats theoretical as urgent | Misses targeted attacks | Silence is not safety |
The single most useful sentence to take from that table. CVSS tells you how bad, EPSS tells you how likely, and CISA KEV tells you it already happened.
None of the three tells you whether the affected component is actually reachable in your environment. That gap is addressed later in this article.
How to combine all three into one prioritization rule
Here is a defensible tiering that a team can implement without a data science function. Treat the thresholds as starting points to calibrate against your own remediation capacity.
Tier | Condition | Target |
|---|---|---|
P0 | In CISA KEV, and the component is deployed | Emergency change, days |
P1 | EPSS probability at or above 0.10, and CVSS 7.0 or above | Current sprint |
P2 | EPSS at or above 0.10, or CVSS 9.0 or above | Next sprint |
P3 | CVSS 7.0 or above, EPSS below 0.10 | Routine patch cycle |
P4 | Everything else | Batch, or accept with a documented reason |
Four notes on applying it.
Calibrate the EPSS threshold to your capacity, not to a blog post. Sort your backlog by EPSS descending, walk down until you hit the number of items you can genuinely fix per cycle, and use that score as your line.
Deployment status is a gate, not a tiebreaker. A CISA KEV entry for software you do not run is not a P0. It is not a finding at all.
Re-run the scoring on a schedule. EPSS changes daily and the CISA KEV catalog grows continuously. A priority assigned three months ago is stale by construction, and the direction of travel is usually upward.
Record acceptances explicitly. P4 with a documented reason is a decision. P4 because nobody looked is an unmanaged risk wearing a tier label.
What risk-based vulnerability management looks like in practice
Risk-based vulnerability management is the programme-level version of the rule above. It replaces "remediate by severity" with "remediate by modelled risk to this organisation".
Four inputs make it work. The first two are common and the last two rarely are.
Vulnerability data. Which CVEs affect which components. This is what scanners provide.
Threat data. EPSS and CISA KEV, which supply the likelihood dimension.
Asset context. Whether the affected component is deployed, internet-facing, and what data it can reach. This input has the largest effect on the final ranking and is usually the weakest.
Reachability. Whether the vulnerable code path is actually invoked in your configuration. A vulnerable function in a linked library that your SCA tooling flags is a materially different risk when it sits on your primary request path versus a library your application never calls into.
The honest reporting metric is not open findings, and it is not mean time to remediate. It is the count of vulnerabilities that are both exploitable and reachable, and the trend of that count over time.
Where vulnerability prioritization still breaks down
Three failure modes survive even a well-run risk-based programme. Each is worth naming.
Fixed in a repository is not fixed in production
A merged patch and a deployed patch are different claims, and most dashboards only measure the first.
The Liquid Network incident in September 2026 is the clearest recent illustration.
A fix for a consensus-level bug in the Elements codebase was merged to public branches around September 1 to 3, but never shipped in a tagged release.
The exploit landed on September 6 and roughly $320 million in Bitcoin left the network in about 23 minutes.
Every ticket in that scenario reads as closed. The full breakdown is in our writeup of that attack path.
An unreleased fix is a public exploitation window
Once a security fix is merged in a public repository, the vulnerability is effectively disclosed to anyone reading the commit log, whether or not an advisory exists.
Patch diffing turns that commit into a working exploit in days. Prioritization frameworks that key on CVE publication date systematically miss this window, because the CVE often does not exist yet.
Severity is a property of the chain, not the component
This is the deepest limitation. Every framework in this article scores individual vulnerabilities in isolation.
Real compromises are chains.
A low-severity information disclosure that leaks an internal hostname, combined with a medium-severity authorization gap, produces a critical outcome that neither component's score predicts.
No amount of per-CVE scoring surfaces that.
Only validating the path end to end does.
Which is the argument for attack path validation alongside prioritization rather than instead of it.
How CodeAnt AI Applies These Signals
Three parts of the platform touch this problem, and being specific about which is more useful than being expansive.
CVSS, EPSS, and a known-exploited filter, on the same row for every CVE. This is the three-signal comparison from earlier in this article, applied to a live target rather than a spreadsheet.
Attack surface management correlates more than thirty data sources continuously, including the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring. The output view lists each CVE with its CVSS severity, its EPSS percentage, and a known-exploited filter, which is the three-signal comparison in one place.
The cadence is the point. This runs daily rather than on a scan schedule, so a newly published CISA KEV entry against software you run surfaces the same day rather than at the next quarterly review.
Deterministic scoring in the AI penetration testing pipeline adds the dimension CVSS cannot. Findings are scored by vulnerability weight, target weight, proximity to data, and reachability, using pure code rather than a model so the result is auditable.
A queue ranked by proximity to data, not raw CVSS. Two findings with similar severity scores can sit far apart here once reachability and target weight are factored in.
Proximity to data is the variable that matters most and that public scoring omits entirely. A defect zero hops from a customer database outranks a higher-CVSS defect three hops away.
Proof of exploitation closes the loop. More than 500 agents chain findings to demonstrate what an attacker actually reaches, on the principle that a detected vulnerability is not a confirmed leak.
For context on what scoring alone misses, CodeAnt has found 150+ CVEs including a CVSS 10.0 vulnerability in pac4j that went undetected for six years.
Those projects represent 2B+ monthly downloads protected.
The Vulnerability Prioritization Checklist
Data foundations
Ingest all three signals. CVSS from NVD, EPSS daily from FIRST, and the CISA KEV catalog. Two out of three is the common failure.
Record the CVSS version alongside every score. A v3.1 and a v4.0 number are not directly comparable.
Use EPSS probability for thresholds and percentile for ranking. Do not mix them.
Context
Gate on deployment status before anything else. An unrun component is not a finding.
Flag internet-facing assets as a separate dimension rather than folding them into severity.
Establish reachability for your top findings. If you cannot answer whether the vulnerable path is invoked, that is the gap to close first.
Operations
Calibrate thresholds to actual throughput. Measure how many items you close per cycle and set the line there.
Re-score on a schedule, because EPSS moves daily and CISA KEV grows.
Track merged versus deployed as distinct states in your workflow.
Document every acceptance with a named owner and a review date.
Reporting
Report exploitable and reachable counts, not open finding counts.
Report your patch window, measured from public fix availability to full deployment.
Where This Leaves You
The three signals are complementary and cheap. All are public, all are free, and combining them takes an afternoon of engineering.
What they cannot give you is environment context or chain awareness. Both of those live in your own infrastructure, and no external feed supplies them.
So the sequence is straightforward.
Use CVSS, EPSS, and CISA KEV to shrink the queue from thousands to dozens, then use reachability and attack path validation to determine which of those dozens actually reach anything.
