Why Fixing Every CVE Is a Waste of Time: The Case for Exploitability-First Vulnerability Prioritisation

The CVE Backlog Trap: Why More Scanning Creates Less Security

If your vulnerability scanner is doing its job, it is probably making you feel worse about your security posture every week. Scan a typical SME environment and you will surface hundreds, sometimes thousands, of CVEs. Each one arrives with a CVSS score, a severity label, and an implicit demand on your time. Patch them all, the conventional wisdom says. Move fast. Reduce your attack surface.

But here is the uncomfortable truth: chasing every CVE is not a security strategy. It is a busywork trap that consumes finite engineering hours, creates patch-related outages, and leaves your team too exhausted to focus on the vulnerabilities that actually get exploited.

The numbers bear this out. The National Vulnerability Database catalogues well over 200,000 CVEs, with roughly 25,000 to 30,000 new entries published each year. Research from the Cyentia Institute consistently suggests that a small minority of published CVEs — often cited as fewer than five percent — are ever exploited in the wild, though the precise figure varies by study methodology and observation window. That means the overwhelming majority of vulnerabilities in your backlog will never be weaponised against you. Yet most SMEs treat every CVSS 7.0-or-above finding as equally urgent, creating a prioritisation crisis that no amount of additional tooling can solve.

The problem is structural. Vulnerability scanners are optimised to find everything. They are not optimised to tell you what actually matters in your specific environment, against your actual threat landscape, given your available resources. When you optimise for raw CVE count — either reducing it as fast as possible or reporting it to leadership as a measure of security progress — you are measuring activity, not risk.

For SMEs without a dedicated security team, this distinction is not academic. Every hour spent patching a theoretical vulnerability is an hour not spent on the handful of flaws that attackers are actively weaponising today. The result is a security programme that looks busy and feels productive but leaves genuine exposure unaddressed.

There is a better way to think about this, and it starts with rethinking what you are actually trying to protect against.

What Exploitability-First CVE Prioritisation Actually Means

Exploitability-first CVE prioritisation is a framework for triaging vulnerabilities based on the likelihood and ease with which they can be exploited in real-world attacks, rather than on their theoretical severity score alone. It shifts the central question from "how bad could this be?" to "how likely is this to be used against us, and is it already happening?"

This is a meaningful distinction. CVSS, the Common Vulnerability Scoring System, was designed to communicate the technical severity of a vulnerability in a standardised way. It does that reasonably well. What it does not do is tell you whether a vulnerability has a working public exploit, whether ransomware groups are actively using it, or whether your specific assets are even exposed to it in a meaningful way. A CVSS 9.8 critical vulnerability in software you do not run, with no public exploit, poses less real-world risk to your organisation than a CVSS 6.5 medium in an internet-facing service that attackers are actively scanning for.

Exploitability-first prioritisation incorporates several layers of context that CVSS ignores:

Exploit availability. Is there a working proof-of-concept or weaponised exploit in the wild? A vulnerability without a usable exploit is far harder to act on maliciously, regardless of its CVSS score.

Active exploitation evidence. Is this vulnerability being used in real attacks right now? Threat intelligence feeds, honeypot data, and government advisories can surface this signal quickly.

Asset exposure and criticality. Is the vulnerable component internet-facing? Does it process sensitive data? Is it part of a system that, if compromised, would allow lateral movement or privilege escalation?

Compensating controls. Do you have WAF rules, network segmentation, or authentication layers that meaningfully reduce the exploitability of this vulnerability in your environment?

When you combine these factors, a very different prioritisation list emerges — one that is smaller, more actionable, and far more defensible when auditors or insurers ask why you made the remediation decisions you did.

The Metrics That Matter: EPSS, CISA KEV, and Real-World Threat Context

Three data sources should sit at the heart of any exploitability-first CVE prioritisation workflow, and none of them require expensive enterprise tooling to access.

Exploit Prediction Scoring System (EPSS)

Developed by the Forum of Incident Response and Security Teams (FIRST), EPSS is a machine-learning model that estimates the probability that a given CVE will be exploited in the wild within the next 30 days. It draws on a wide range of signals including exploit database activity, dark web chatter, social media mentions, and historical exploitation patterns.

EPSS scores range from 0 to 1 (or 0% to 100%), and the distribution is heavily skewed. The vast majority of CVEs carry EPSS scores below 0.1%, meaning the model assigns a less than one-in-a-thousand chance of exploitation in the near term. The small cohort of CVEs with EPSS scores above 10% or 20% represent a genuinely elevated and time-sensitive risk. Combining EPSS with CVSS — prioritising high-severity CVEs that also carry high EPSS scores — can help reduce your actionable list without meaningfully increasing your risk exposure, though organisations should calibrate thresholds to their own risk appetite.

CISA Known Exploited Vulnerabilities (KEV) Catalogue

Maintained by the US Cybersecurity and Infrastructure Security Agency, the KEV catalogue is a curated list of vulnerabilities that have been confirmed as actively exploited in real-world attacks. Unlike EPSS, which is probabilistic, KEV entries represent confirmed exploitation. If a CVE appears in the KEV catalogue, it is a near-immediate remediation priority regardless of its CVSS score.

CISA mandates that US federal agencies remediate KEV entries within defined timeframes, but the catalogue is equally valuable for SMEs worldwide. It is freely available, regularly updated, and represents some of the most reliable threat intelligence you can access at no cost.

Threat Intelligence and Industry Context

Beyond EPSS and KEV, contextualising your CVE backlog against your industry's threat landscape adds another prioritisation layer. Ransomware operators tend to target specific sectors with specific tooling, though attack patterns shift over time and organisations should consult current sector-specific advisories rather than relying on generalisations. If you operate in healthcare, financial services, or legal services, your threat profile is likely to differ from a SaaS startup serving consumers. Sector-specific threat intelligence — available through industry ISACs, government cybersecurity agencies, and managed security providers — helps you understand which attack patterns are most relevant to your environment and which vulnerability classes attackers in your sector are actively weaponising.

Together, EPSS, KEV, and sector-relevant threat intelligence form a triage framework that is both practically manageable and analytically sound. You are no longer guessing at priority based on a single severity score. You are making evidence-based decisions grounded in real-world exploitation data.

How SMEs Can Build an Exploitability-First Triage Workflow

Implementing exploitability-first CVE prioritisation does not require a security operations centre or a team of analysts. It requires a structured process that your existing IT or development team can execute consistently, even if security is only part of their responsibilities.

Here is a practical workflow framework designed for SMEs:

Step 1: Inventory and scan on a regular cadence

You cannot prioritise what you cannot see. Establish a regular scanning cadence — weekly for internet-facing assets is a reasonable baseline — and maintain an accurate asset inventory that maps CVEs to specific systems and services. Tag assets by exposure level (internet-facing, internal, critical infrastructure) and data sensitivity.

Step 2: Filter by KEV first

Before anything else, cross-reference your scan results against the CISA KEV catalogue. Any CVE that appears there should jump to the front of your remediation queue with a 24 to 72 hour response target for critical systems. This step alone often surfaces the small number of CVEs in your backlog that represent genuine, immediate risk.

Step 3: Apply EPSS thresholds

For the remaining CVEs, filter by EPSS score. A commonly used starting threshold is 10% — any CVE with an EPSS score above this level may warrant prompt attention, though the right threshold will depend on your organisation's risk appetite and available resources. CVEs below 1% EPSS that are not in KEV can typically be scheduled for routine patch cycles or accepted as low-priority risk.

Step 4: Overlay asset criticality and exposure

For the CVEs that survive your EPSS filter, apply context. A high-EPSS CVE in an internal-only system protected by multi-factor authentication and network segmentation is a different risk proposition than the same CVE in an internet-facing web application. Score each finding by the combination of exploitability signal and asset exposure to produce your final priority ranking.

Step 5: Categorise and assign remediation targets

Group your triaged CVEs into three buckets: immediate remediation (KEV or EPSS above 20% in exposed assets), scheduled remediation (EPSS 5-20% or high-severity in less exposed assets), and accepted or deferred risk (low EPSS, no KEV, with documented rationale). Each category should have a defined remediation SLA and an owner.

Step 6: Review and recalibrate monthly

EPSS scores change as new exploit activity emerges. A CVE that scored 0.5% last month might score significantly higher today because a ransomware group published a working exploit. Build a monthly review into your workflow to recalibrate priority rankings based on updated EPSS data and new KEV entries.

This process is repeatable, resource-efficient, and produces a defensible record of your remediation decisions — which leads to the next critical consideration.

Making It Audit-Ready: Documenting Defensible Remediation Decisions

One of the underappreciated benefits of exploitability-first CVE prioritisation is that it produces exactly the kind of documented, evidence-based decision trail that auditors, cyber insurers, and regulatory bodies want to see.

Regulatory frameworks including ISO 27001, SOC 2, DORA, and various national implementations of NIS2 generally require organisations to demonstrate a risk-based approach to vulnerability management — one where prioritisation decisions are grounded in assessment rather than guesswork, and where accepted risks are explicitly acknowledged and documented. Organisations should verify the specific requirements of any framework applicable to them, as obligations vary.

When you prioritise using EPSS and KEV data, every remediation decision is traceable to objective, publicly available threat intelligence. When you defer a low-EPSS, non-KEV vulnerability, you can document the rationale: the EPSS score at the time of assessment, the compensating controls in place, the asset's network exposure, and the scheduled review date. This is not corner-cutting. It is risk management.

For practical documentation, consider maintaining a vulnerability register that captures for each CVE: the discovery date, the CVSS score, the EPSS score at triage, whether it appears in KEV, the asset criticality rating, the assigned priority tier, the remediation action taken or deferred, and the rationale for any deferral. A well-maintained vulnerability register is one of the most powerful artefacts you can present during a security audit or cyber insurance renewal. It demonstrates maturity, intentionality, and a programme that is responsive to real-world risk rather than checkbox compliance.

For regulated SMEs in financial services, healthcare, or legal sectors, this documentation discipline is not optional — it is the foundation of a defensible compliance posture. And unlike many compliance requirements, building this kind of record can reduce overall workload compared to trying to remediate everything, because it replaces frantic patching activity with structured, prioritised decision-making.

Getting Started Without Overhauling Your Entire Security Programme

The most common objection to implementing exploitability-first CVE prioritisation is that it sounds like a significant lift for a team that is already stretched. In practice, this approach aims to reduce the volume of work by giving you a principled basis for saying "not now" to a large portion of your CVE backlog.

Here is how to get started without a full programme overhaul:

Use what you already have. If you are already running a vulnerability scanner, your tooling is sufficient to get started. EPSS scores and KEV data are freely available via FIRST's API and CISA's website respectively. Many commercial scanners, including mid-market tools popular with SMEs, now surface EPSS data natively or as an integration.

Start with your most exposed assets. You do not need to apply this framework to your entire estate on day one. Begin with internet-facing systems and any assets that process regulated or sensitive data. These are the highest-consequence targets and the most likely attack entry points.

Create a simple triage template. A spreadsheet or lightweight ticketing workflow with the fields described in the previous section is enough to start building your vulnerability register. You do not need a dedicated vulnerability management platform — though these do become valuable as you scale.

Set realistic remediation SLAs. Define what "immediate," "scheduled," and "deferred" mean in your context. For most SMEs, immediate means within 72 hours for KEV entries on critical systems, seven to fourteen days for high-priority EPSS findings, and the next scheduled maintenance window for lower-priority items. Written SLAs, even simple ones, transform vulnerability management from an informal scramble into a manageable programme.

Get external support where needed. If your team lacks the capacity or expertise to run this process consistently, a managed vulnerability management service or a virtual CISO engagement can implement and maintain the workflow on your behalf. The key is ensuring that whoever is managing your CVE backlog is applying exploitability-first logic rather than simply reporting raw counts.

Exploitability-first CVE prioritisation is not a silver bullet, and it does not mean ignoring vulnerabilities. It means allocating your finite security resources where they will have the greatest impact on your actual risk exposure. For SMEs without the luxury of large security teams or unlimited patching windows, that is a practical approach to staying secure in an environment where the vulnerability firehose shows no sign of slowing down.

If you are ready to move from reactive CVE firefighting to a structured, risk-based vulnerability management programme, Kordax can help you build a workflow that fits your team, your compliance requirements, and your threat landscape.

Originally published at Profile Strategy Hub.