I have watched teams triage the same critical CVE for the seventh time this quarter because a scanner surfaced it on an unreachable code path and the team's policy is "fix all criticals within 30 days." The policy sounds responsible. It is, in practice, responsible for an enormous amount of wasted engineering time and a backlog that is indistinguishable from noise. My thesis for this piece: CVSS-only prioritization is the regulatory-compliance equivalent of a stopped clock — occasionally correct, reliably wrong, and expensive to trust. Programs that still lean on it as their primary ranking signal are operating with early-2010s rigor in a late-2020s threat landscape.
This is not an argument against CVSS. CVSS is a reasonable scoring rubric for the theoretical severity of a vulnerability in a vacuum. The problem is that production is not a vacuum, and the decision you are trying to make — what to fix right now — requires information CVSS does not and cannot encode.
What Does CVSS Actually Tell You?
It tells you how bad a vulnerability could be in a worst-case configuration, in the abstract. That is the entire scope of the score. It does not tell you whether the vulnerability is reachable in your application. It does not tell you whether the vulnerable function is invoked at runtime. It does not tell you whether an exploit exists in the wild. It does not tell you whether the affected service is internet-facing, in a regulated environment, or sitting on a lab VM no one has used in two years.
The designers of CVSS were explicit about this. The scoring model was always intended to be a starting point for organizational risk assessment, not the end point. The industry collectively forgot that caveat somewhere around 2017, and we have been paying for it ever since.
The practical consequence is that every scanner output looks like a pile of sevens, eights, and nines. A vulnerability with a reachable exploitable path on an internet-facing auth service scores the same as one buried three transitive dependencies deep in a library that is imported but never called. Treating them as equivalent is not just inefficient — it is actively harmful, because it trains engineers to ignore the whole queue.
What Is Missing From a CVSS-Only View?
Four dimensions of information, each of which moves the priority substantially.
The first is reachability. Static and dynamic analysis can determine whether the vulnerable function is in the call graph of the running service. If it is not, the finding is a different kind of issue — worth tracking, but not worth blocking a release. If it is, the urgency is real. The gap between these two cases is often two orders of magnitude in actual risk.
The second is exploitability in the wild. EPSS scores, CISA's Known Exploited Vulnerabilities catalog, and threat intelligence feeds tell you whether attackers are currently exploiting the issue. A CVSS 9.8 that no one has ever exploited is a lower operational priority than a CVSS 7.2 that is being actively weaponized. CVSS cannot distinguish these cases. EPSS, for all its flaws, can.
The third is business context. A vulnerability on a service that handles payments in a regulated jurisdiction is a different kind of problem from one on a marketing site. The technical severity may be identical. The remediation urgency is not. Business context is organization-specific and cannot live in a global score.
The fourth is environmental context. Is the service exposed to the internet? Does it run with reduced privileges? Does it sit behind a WAF that happens to block the exploit pattern? Compensating controls do not make a vulnerability go away, but they do shift the economics of when to fix it.
Any prioritization system that ignores these four dimensions is producing advice that is, at best, partially useful.
Is EPSS the Answer?
EPSS helps, significantly, but it is not a complete replacement. It is a probabilistic estimate of exploitation in the next 30 days, based on historical signal. It is the best publicly available answer to "is anyone likely to actually use this?" and it correlates far better with real-world exploitation than CVSS does.
The limitation is that EPSS is a global score. It does not know whether a given CVE is reachable in your code, relevant to your architecture, or in scope for your threat model. It is one signal among several. Programs that swapped CVSS-only for EPSS-only repeated the original mistake with a different number.
The right approach is ensemble: CVSS for a baseline severity frame, EPSS for exploitation probability, reachability analysis for relevance to your codebase, runtime telemetry for exposure, and business labels for blast radius. The composite is what belongs at the top of a priority queue.
How Do You Actually Build a Multi-Signal Priority Queue?
Start with the assumption that no single score is authoritative. The job of the prioritization system is to combine multiple signals into a decision and to be transparent about how it did so.
Reachability first. If a finding is not reachable in a way that matters, deprioritize aggressively. This is the single biggest lever for backlog reduction — typical programs see 40 to 70 percent of their "critical" backlog evaporate when reachability is applied honestly.
Exploitability second. For the findings that remain, weight by EPSS and known-exploited-vulnerability status. A finding that is reachable and actively exploited is in a different category from one that is reachable but has no in-the-wild exploit.
Business context third. Services that handle regulated data, that are internet-facing, or that are critical path to revenue get a multiplier. This is where labels produced by the business, not the security team, belong in the pipeline.
CVSS fourth, as a tiebreaker and a sanity check. If a composite score is high but the CVSS base is low, investigate. If CVSS is high but the composite is low, trust the composite and document the reasoning.
Transparency is non-negotiable. Engineers need to see why a finding is ranked where it is. "High priority because multi-signal score" is not enough — you need to surface the reachability result, the EPSS percentile, the business label, and the CVSS base, so a skeptical developer can audit the logic and disagree when warranted.
Do Regulators Accept This?
More than they used to, and more than many programs assume. Major frameworks — FedRAMP, NIST 800-53 revisions, PCI DSS 4, the EU Cyber Resilience Act — have explicit language accommodating risk-based prioritization. The days when "all CVSS 7+ fixed in 30 days" was the required answer are largely over, at least in the frameworks that have updated recently.
The trick is documentation. Regulators accept risk-based prioritization when you can explain it, defend it, and produce evidence that the methodology is consistently applied. They do not accept hand-waving. If your program cannot, on demand, show why a given finding was deprioritized and who authorized that decision, a regulator will reasonably assume you are just ignoring findings.
This is another reason a workflow-based prioritization system is better than a dashboard. A workflow produces an audit trail. A dashboard produces a screenshot.
What Should Be Retired Immediately?
SLA language pegged to CVSS alone. If your security policy says "all critical vulnerabilities must be remediated within N days," replace it with risk-tier SLAs that reflect the composite score. "Tier 1: reachable + exploitable + internet-facing — 7 days. Tier 2: reachable + exploitable — 30 days. Tier 3: reachable only — 90 days. Tier 4: not reachable — tracked, no SLA." The numbers are illustrative; the shape is the point.
Also retire the practice of paging engineers on high-CVSS findings without reachability filtering. Every false alarm trains the team to distrust the signal. Every real alarm missed because it was buried in noise is an incident waiting to happen.
How Safeguard.sh Helps
Safeguard.sh runs a multi-signal prioritization engine by default. Every finding is evaluated for reachability in the actual call graph, enriched with EPSS and KEV data, weighted by runtime exposure, and scored against business-owner-defined criticality labels. The output is a priority queue engineers can trust, with transparent reasoning for every ranking. The noise that used to dominate backlogs — unreachable, unexploited, low-blast-radius findings — is deprioritized automatically. Audit trails are produced as a byproduct of the workflow, so the program remains defensible to regulators without requiring a parallel documentation effort. CVSS is still in the signal set. It is just not the only one deciding what ships on Monday.