The CVE Flood: Why “Patch Everything” Is No Longer a Strategy
The numbers speak for themselves: the National Vulnerability Database (NVD) recorded more than 28,000 newly reported CVEs in 2023 — an increase of over 15 percent compared with the previous year. Since 2017, annual CVE volume has nearly doubled. For security teams, this translates into a simple operational truth: complete remediation is no longer a realistic objective.
The consequences are systemic. Teams spend the bulk of their capacity working through scan reports, prioritising by severity score, and yet never catch up. Patches are deployed without any measurable improvement in the actual risk posture. The classic mantra — scan, report, patch — simply no longer works in environments with thousands of assets and hundreds of thousands of findings. The result is not a weak security posture caused by insufficient effort, but by misplaced priorities.
The Checklist Trap: What Traditional Vulnerability Management Gets Wrong
The dominant model in vulnerability management follows a compliance-driven workflow: a scanner identifies vulnerabilities, a report is generated, tickets are distributed by CVSS score. Anything with CVSS ≥ 9.0 is “Critical,” anything ≥ 7.0 is “High” — and resources are allocated accordingly.
The problem is not the CVSS system itself, but its use as the sole prioritisation criterion. CVSS evaluates the technical properties of a vulnerability in theory — attack complexity, required privileges, scope. What CVSS does not answer: is this vulnerability currently being actively exploited? Is the affected asset business-critical? Is it even reachable from the internet?
A CVE with a CVSS score of 9.8 on an isolated development system that cannot reach the production network is operationally far less urgent than a 6.5 vulnerability in a publicly exposed application for which an exploit is already in circulation. Prioritising exclusively by CVSS wastes capacity on low-impact findings while leaving genuinely dangerous gaps open.
Risk-Based Prioritisation: The Metrics That Actually Matter
A risk-based approach combines several data points into a context-aware risk picture:
EPSS (Exploit Prediction Scoring System): Developed by FIRST, this model estimates — based on threat intelligence, code analysis and historical exploit data — the probability that a vulnerability will be exploited in the wild within 30 days. A CVE with an EPSS score of 0.95 deserves immediate attention regardless of its CVSS value.
CISA KEV (Known Exploited Vulnerabilities): The CISA list documents vulnerabilities that are demonstrably being actively exploited. KEV entries are not a forecast but evidence — and should automatically be placed in the highest risk class in any prioritisation model.
Image: Example of a CVSS/EPSS matrix for urgency assessment (from TrustSource)
Asset Exposure: A vulnerability on an internet-exposed, non-WAF-protected system with privileged data access must be assessed fundamentally differently from the same vulnerability in an air-gapped environment. Asset inventory and network topology must feed into the scoring.
Business Context: Which systems are business-critical? Which process personal data or are subject to regulatory requirements? This information transforms a technical risk score into an organisation-specific prioritisation.
Combining these signals allows a prioritisation logic that no longer asks “how technically severe is this vulnerability?” — but rather “how likely is exploitation, and what damage would it cause in our specific context?”
Building a Risk-Based Vulnerability Pipeline: From Detection to Decision
Operational implementation requires integration on several levels. A functioning risk-based pipeline approach consists of the following elements:
Detection Layer: Vulnerability scanners (Qualys, Tenable, Rapid7, etc.) deliver the raw findings. These must be enriched with an up-to-date asset inventory — ideally automated via CMDB integration or agent-based discovery.
Enrichment Layer: Each finding is enriched with threat intelligence: EPSS score, KEV status, public exploit availability (via ExploitDB, Metasploit modules, GitHub PoCs). This step transforms the technical finding into a contextualised risk object.
Prioritisation Layer: Based on defined rules — for example, “KEV entry + internet-exposed asset = P1 with 48h SLA” — findings are classified automatically. The prioritisation logic must be documented, traceable and reviewed regularly.
Ownership and SLA: Security identifies and prioritises, engineering remediates. Clear ownership models with defined escalation paths are critical. SLAs should be defined based on risk — not “all Criticals within 30 days,” but “P1 findings (KEV + exposure) within 48 hours, P2 within 7 days, P3 within 30 days.”
Measuring What Matters: KPIs for Risk Reduction Instead of Patch Velocity
The most common measurement mistake in vulnerability management: using patch rate as the primary KPI. A high patch rate can even be counterproductive with poor prioritisation — when low-risk findings are patched while critical gaps remain open.
More meaningful metrics for a risk-based programme:
- MTTR by risk class: Mean Time to Remediate broken out by P1/P2/P3. Is the MTTR for the highest risk classes improving? That is the relevant question.
- KEV Coverage Rate: What percentage of CISA KEV entries are patched or mitigated in your environment? This metric is directly tied to real-world threat activity.
- Reduction of Exploitable Attack Surface: How many actively exploitable findings (EPSS > 0.5 + exposure) exist over time? A downward trend indicates genuine risk reduction.
- Risk Acceptance Rate: How many findings are formally accepted, and on what risk basis? Transparency here protects against implicit risk.
These metrics enable stakeholder communication that goes beyond “we have patched X percent of CVEs” — towards “our exposure to actively exploited vulnerabilities has dropped by Y percent.”
Common Mistakes and How to Avoid Them
The rollout of risk-based vulnerability management processes often fails in predictable places:
Tool overload without process maturity: Integrating four different scanners, two threat intel feeds and a SOAR system before basic processes are defined produces more noise than clarity. Tool decisions should follow process decisions, not the other way around.
Lack of developer integration: Vulnerability management that takes place exclusively within the security department fails at remediation. Engineering teams must be involved early — findings must be visible in their toolchain (Jira, GitHub Issues), and security must provide context, not just tickets.
Uncalibrated risk models: A risk model that was calibrated in 2022 and has run unchanged since then no longer reliably reflects the current threat landscape. Regular reviews — at least quarterly — are not optional but mandatory.
Risk-based as a justification for not patching: The most dangerous misuse of the approach: findings are classified as “low risk” to defer remediation without the risk model actually supporting that assessment. Risk-based prioritisation means intelligent patching — not less patching.
From Reactive to Strategic: The Maturity Path
Vulnerability management evolves along a maturity model:
- Ad hoc: Scanner output is processed manually, no consistent prioritisation, high MTTR, reactive response to incidents.
- Defined: Documented processes, CVSS-based prioritisation, SLA definitions — but no context enrichment yet.
- Risk-Driven: Integration of EPSS, KEV, asset context; automated prioritisation logic; risk-based SLAs and KPIs.
- Continuous: Closed feedback loops between security, engineering and the business; continuous calibration of the risk model; vulnerability management as input for strategic architectural decisions.
Teams at level 1–2 should first prioritise asset inventory and KEV integration — these are the two measures with the greatest immediate impact. Teams at level 2–3 should tackle EPSS integration and risk-based SLA definitions. Level 3 teams work on continuous calibration and the strategic embedding of the programme.
Three key takeaways:
- CVSS alone is not a prioritisation criterion — without exploitability data (EPSS, KEV) and asset context, it leads to systematically wrong priorities.
- Patch rate is the wrong KPI — what matters is reducing exposure to actively exploited vulnerabilities, measurable via KEV Coverage and exploitable attack surface.
- Risk-based vulnerability management is not a tooling question, but a matter of process and culture: without developer integration, clear ownership models and regular calibration, the model remains ineffective.