Most remediation programmes in 2026 are still drowning in their own queues, and the reason is almost always the same: the queue is sorted by CVSS score. CVSS was designed to describe the severity of a vulnerability in the abstract. It was never designed to tell a team which of their open findings to fix first. A queue of 400 findings sorted by CVSS will mix exploited zero-days reachable from the internet with theoretical issues in code paths nobody has run since 2019. Fixing the queue top-to-bottom is a guaranteed way to spend effort on the wrong things.
The replacement is not exotic. Reachability analysis plus EPSS, weighted against asset criticality, gives any team a prioritisation order that is defensible to engineering, auditors, and an executive who wants to know why a particular finding was fixed first.
Why CVSS Alone Fails
CVSS describes a vulnerability's intrinsic severity: the attack vector, the attack complexity, the privileges required, the impact on confidentiality, integrity, and availability. It says nothing about whether the affected code is reachable in the application that contains it. A high-CVSS vulnerability in a function the application never calls is harmless. A medium-CVSS vulnerability in a function on the request hot path is dangerous.
CVSS also says nothing about whether the vulnerability is being exploited in the wild. A 9.8 CVSS that has never been seen in a working exploit is less urgent than a 6.5 CVSS that has working exploit code circulating and active scanning observed. CVSS treats them the same.
Teams that prioritise by CVSS alone end up fixing many things that did not need fixing first while leaving the things that did. This pattern is what produces the embarrassing findings in incident postmortems: the breach used a 7.2 CVE that had been open for six months because it was below the team's "critical" cutoff.
What Reachability Adds
Reachability analysis traces from the application's entry points through the dependency graph to determine whether the vulnerable code is actually invoked. The analysis is not flawless. It can produce false negatives in dynamic codebases that load modules at runtime, and it can produce false positives when entry points are over-approximated. But it is dramatically better than no signal at all, and the false negatives can be mitigated by treating "unknown reachability" as a separate state from "demonstrably unreachable".
The output is three buckets per finding. Reachable: the affected code is on a call path from an entry point. Unreachable: there is no call path. Unknown: the analysis could not conclude, often because the code uses dynamic dispatch or reflection.
Reachable findings are the ones that matter most. Unknown findings need human triage but are not reflexively assumed dangerous. Unreachable findings can be deprioritised aggressively, with the analysis stored as evidence so the deprioritisation is defensible if questioned later.
What EPSS Adds
EPSS, the Exploit Prediction Scoring System, is a probability that a given CVE will be exploited in the next 30 days. It is computed daily from a model trained on observed exploitation behaviour. EPSS is not a perfect predictor either, but it is the best public signal of which vulnerabilities the real-world threat landscape cares about.
EPSS scores are heavily skewed. The vast majority of CVEs sit at very low probability. A small share sit above 10 percent. A tiny share sit above 50 percent. The high-EPSS vulnerabilities are the ones to act on first, especially when they coincide with reachable code.
EPSS is also dynamic. A CVE that scored 2 percent six months ago may score 40 percent today because exploitation has been observed. A prioritisation system that uses EPSS has to refresh scores continuously. A static export from the time of finding is worse than nothing because it gives false confidence.
Combining The Signals
A defensible prioritisation order combines reachability, EPSS, asset criticality, and CVSS in roughly that order of weight. Reachability is a hard filter: unreachable findings drop several priority tiers. EPSS is the next strongest signal: high-EPSS reachable findings rise to the top regardless of CVSS. Asset criticality refines further: a reachable high-EPSS finding in a customer-facing payment service outranks the same finding in an internal staging tool. CVSS contributes as a tie-breaker.
The output is a single ordered queue per project, with the top of the queue being the findings most worth fixing first. Each entry carries the reasoning behind its position so a reviewer or auditor can see why one finding outranks another. The reasoning is the audit trail. A queue without reasoning is not defensible.
Tier Boundaries
A useful prioritisation order is not a flat list. It has named tiers with policy attached. Tier one is reachable, high-EPSS findings on critical assets. These are auto-PR'd within hours and routed to a high-priority review pool. Tier two is reachable, high-EPSS on non-critical assets, or reachable medium-EPSS on critical assets. Auto-PR within a day, standard review pool. Tier three is reachable low-EPSS, or unknown reachability with high EPSS. Auto-PR within a week, batched into manageable groups. Tier four is unreachable findings. Documented as deprioritised, no auto-PR unless the underlying analysis changes.
Tiers make the policy concrete. Engineering teams can plan around them. Security teams can defend them. Executives can understand them. A flat queue ordered by a numeric score does none of those things.
Avoiding Bad Failure Modes
Prioritisation tooling has its own failure modes that are worth flagging.
The first is over-trusting reachability. A reachability analysis that classifies a finding as unreachable should be revisited periodically. Application code changes. A function that was unreachable last month may be on the hot path this month after a refactor. Safeguard re-runs reachability on every push and updates classifications automatically.
The second is over-trusting EPSS. EPSS is a probability, not a certainty. Some 1 percent CVEs have been exploited spectacularly when the right conditions appeared. The tier boundaries should treat low EPSS as "likely lower priority" not "definitely safe to ignore for years". An annual review of long-deprioritised findings catches the cases where EPSS has shifted.
The third is letting prioritisation become a reason to never fix anything. Some teams use the tier system as cover to ignore tier four indefinitely. The right answer is to clear tier four through bulk remediation periodically, not to let it grow forever.
Communicating The Order To Engineering
Prioritisation only matters if engineering teams accept the order. The way to earn that acceptance is to make the reasoning visible. When a fix PR lands in front of a reviewer, the evidence panel includes the reachability classification, the EPSS score at the time the PR was opened, the asset criticality of the project, and the resulting tier. The reviewer can see why this finding was fixed before another. They can challenge the classification if they have local knowledge that contradicts it.
The same information appears on the security team's dashboard, on the executive briefing, and on the auditor-facing report. Consistency across surfaces builds trust. A team that gets one story from the reviewer pane and another from the dashboard will trust neither.
Prioritisation As An Input, Not The Whole Programme
Prioritisation is necessary but not sufficient. A perfect queue is wasted if the rest of the remediation pipeline is broken. The queue feeds into auto-PR generation, verification, human review, and merge. Each of those stages has its own design decisions covered elsewhere in this series. Prioritisation by reachability and EPSS is the front-end that determines what the rest of the pipeline works on.
How Safeguard Helps
Safeguard prioritises findings using continuously refreshed reachability analysis, daily EPSS scores, asset criticality, and CVSS as a tie-breaker. The output is a tiered queue per project with named tiers and policy attached, where every position is defensible by the reasoning shown alongside it. Tier one fixes are auto-PR'd within hours, tier four findings are deprioritised with documented evidence, and the analysis is rerun on every push so the order stays honest as the codebase evolves. Teams that adopt this prioritisation report sharply lower remediation effort for the same security outcome, because the right things get fixed first.