If CVE Fails, We Can Finally Start Focusing on the Fixes Rather Than the Vulnerabilities

The Obsession with Enumeration

Let’s be honest: we’ve built a security apparatus that’s more comfortable enumerating problems than solving them. Security teams chase down CVE IDs like Pokémon cards, and dashboards light up with every new disclosure. But here’s the problem: identifying a vulnerability doesn’t mean it gets fixed. In fact, it often ends there.

We’ve created a culture of counting vulnerabilities rather than resolving them. Worse, we’ve made that count the metric of success. Vulnerability scanners don’t measure risk—they measure bulk, like a vendor selling you security by the kilo. The result? More findings, more noise, and more justification for tools that rarely move the needle on actual risk.

CVE as a Crutch

The CVE Program was never meant to be the centerpiece of our remediation strategy—it was designed to standardize how vulnerabilities are referenced. But somewhere along the way, it became the security language. That’s led to over-reliance, misaligned incentives, and a remediation bottleneck. Organizations focus on CVE-labeled issues, even when the context (or lack thereof) makes the actual risk minimal or already mitigated.

This dependence on enumeration has left us reactive, not resilient.

But How Do We Prioritize Without CVEs?

The obvious question: if we stop focusing on CVEs, how do we know what to fix first?

The answer is: context—something the CVE system has never provided on its own.

Fix-centric security doesn’t mean abandoning prioritization. It means enhancing it using richer signals:

• Asset Context: Not all systems are equal. A critical vuln on a dev box isn’t the same as one on a production server handling PII. Prioritization should start with understanding where the vulnerability lives.
• Exploitability Signals: Is the issue actively exploited in the wild? Is it reachable from the internet? Can it be triggered without authentication? Tools like EPSS (Exploit Prediction Scoring System) and threat intel feeds give better risk insight than a CVSS score ever could.
• Dependency Usage: Is the vulnerable function even used in your code path? Is it in a test dependency? Software composition analysis tools can now answer these questions, giving teams permission to not fix issues that pose no actual threat.
• Fix Availability and Impact: Sometimes, the fix is a one-line config change. Sometimes it’s a breaking upgrade. Prioritization should consider the cost of remediation alongside the risk.

Instead of chasing CVE numbers, teams should be asking:

What fixes are easy to apply, remove real risk, and improve our resilience today?

A New Direction: Fix-Centric Security

If CVE falters, it could finally catalyze a long-overdue shift: from vulnerability-centric to fix-centric security.

Imagine a world where instead of asking “What CVEs do we have?”, organizations ask “What fixes have we shipped this week?” Fixes are tangible. They’re measurable. They’re what actually reduces risk.

This doesn’t mean CVEs are irrelevant. It means they should serve as a signal—not the goal. It’s time for security teams, vendors, and regulators to invest more in:

• Automated remediation pipelines

• Patch adoption telemetry

• Risk-based prioritization over list-based triage

• Shared fix intelligence, not just shared vulnerability lists

Reclaiming Security’s Purpose

The CVE program’s struggles expose a deeper issue: we’ve mistaken cataloging risk for mitigating it. This is a moment to realign security around its core purpose—protection through action. If CVE goes down, it might just be the best thing that ever happened to cybersecurity.

Because when enumeration fails, maybe we’ll finally fix what matters.