Ask five security teams which vulnerability they would patch first and you will often get five different answers, all pulled from the same scanner export. The data is not the problem. A weekly scan can return thousands of findings, each with an identifier, a severity number, and a probability that moves overnight. The difficulty is that those numbers answer different questions, and plenty of teams quietly treat them as interchangeable.

Here is what each one actually tells you, where each one misleads, and how to combine them into a queue you can defend to a CISO, an auditor, and the engineer who has to rebuild the box.

Three systems, three questions

CVE answers what is this? It is an identifier — a shared name for a specific vulnerability so that a vendor advisory, a scanner finding, and an incident write-up all point at the same flaw.

CVSS answers how bad would this be? It is a severity score from 0 to 10, derived from a vector describing attack path, complexity, privileges required, and impact.

EPSS answers how likely is someone to exploit this? It is a probability between 0 and 1, refreshed daily, based on observed exploitation signals.

Identity, severity, likelihood. Drop one and the priority list tilts.

CVE: a name, not a verdict

A CVE tells you nothing about risk. The same ID format covers a critical remote code execution flaw in an internet-facing gateway and a hardcoded credential in a developer sample project that nobody deploys. Both are CVEs. Only one deserves your evening.

Two practical consequences. First, "no CVE" does not mean "no problem" — vendor advisories, privately disclosed issues, and misconfigurations sometimes arrive without an identifier, and a scanner that only keys on CVE IDs will miss them. Second, CVE assignment lags discovery. A flaw can be exploited for weeks before the record exists, so treat public exploit chatter and vendor bulletins as first-class sources.

Use CVE IDs for one job: matching records across tools so that two systems are arguing about the same thing.

CVSS: severity under stated assumptions

CVSS is where most prioritization quietly breaks. The base score assumes a worst-case deployment: the vulnerable component is present, reachable, and unmitigated. Nothing in the base score knows whether the service sits behind a VPN or on a hardened internal subnet.

Read the vector string, not just the number. This shape is the one that should raise your pulse:

• AV:N — reachable over the network
• AC:L — no special timing or race condition required
• PR:N — no credentials needed
• UI:N — no user has to click anything

Compare that with a 9.8 that requires local access plus an authenticated admin account. Same number, very different Tuesday. If your tooling supports it, use the environmental metrics to reflect your actual exposure, and the threat metrics in CVSS v4.0 to account for exploit maturity. A score you have tailored to your environment is worth more than the generic published one — as long as you write down what you changed and why.

EPSS: the probability, and its limits

EPSS scores the likelihood of exploitation in the near term, and it is genuinely useful for one thing above all: ranking the middle of a large pile. A finding with a high EPSS and a finding with a trace-level EPSS are not the same problem, even when their CVSS scores match.

Know the edges, though:

• A low score is not a guarantee of safety. Targeted campaigns against niche software generate little public signal, and EPSS is built on public signal.
• It has no idea what your estate looks like. Every asset holding that vulnerable package gets the same probability.
• Scores move. Yesterday's 0.03 can be tomorrow's 0.6 when a proof-of-concept goes public. A threshold set once and never revisited is a false comfort.

For confirmed, in-the-wild exploitation, skip the debate. CISA's Known Exploited Vulnerabilities catalog and vendor confirmations exist precisely for that, and they should override anything a probabilistic model says.

A triage workflow that holds up

Order matters here. Work down the list and stop when a finding lands in a tier you can act on:

1. Is it being exploited? Check KEV, vendor advisories, and your own telemetry. Confirmed exploitation goes to the front regardless of score.
2. Is it reachable? Internet-facing, unauthenticated, and in active use means act now. Internal-only behind SSO means track it, not panic.
3. What does the vector say? Pre-auth, network-reachable, low complexity is the shape that ages badly.
4. What does EPSS add? Use it to sort the remaining pile and to set a cutoff that matches the number of patches your team can actually ship in a week.
5. What is the blast radius? Identity providers, CI/CD pipelines, domain controllers, and anything holding customer data get a bump.
6. Write the deadline. A tier without a date is a wish.

A quick illustration

Two findings land on the same morning. Finding A scores 9.8, but it lives in an internal reporting service behind single sign-on, EPSS is negligible, and no exploit exists. Finding B scores 7.5 in the VPN concentrator, has a public proof-of-concept, and EPSS has been climbing all week. Patch B first. The 9.8 can wait its turn in the normal cycle, and if anyone asks why, you have a one-paragraph answer backed by two independent signals.

Make the numbers serve the decision

Pick a small set of rules and apply them consistently: confirmed exploitation beats everything, reachability beats raw severity, EPSS breaks ties in the middle, and asset criticality overrides all of it when the target matters enough. Review your EPSS threshold monthly, since the scores underneath it shift constantly. Document the exceptions you grant, because the value of this process is not that it produces a perfect order — it is that it produces an order you can explain six months later when someone asks why that 9.8 sat unpatched for a quarter.

None of these three systems will make the decision for you. Used together, they narrow a thousand findings down to the handful that deserve attention this week, which is the only prioritization that ever mattered.

Photo: MART PRODUCTION / Pexels