CVE 2025
Is CVE Still Relevant in 2025? Insights from Ron Gula
Hi there, it's Ron Gula from Gula Tech Adventures. In this post, I want to take a look at something foundational to cybersecurity—but often misunderstood or taken for granted: the Common Vulnerabilities and Exposures (CVE) program.
There’s been a lot of chatter lately around CVE, especially with the recent news of the MITRE-run program losing and then regaining funding. While that’s certainly worth talking about, I want to focus less on the politics and more on the real-world relevance, history, and future of CVE. After all, I've spent over two decades in cybersecurity and have seen firsthand how CVEs shape everything from incident response to national security.
CVE Origins: Back When “We Didn’t Speak CVE”
My first hands-on experience with the CVE program was back when my wife and I were running Network Security Wizards. At cybersecurity conferences, MITRE reps would show up wearing badges that said “We Speak CVE” and encourage vendors to adopt the naming standard.
A “We Speak CVE” Booth Sign
Back then, we didn't have a universal language for describing vulnerabilities. Different vendors and researchers might refer to the same bug by completely different names. That made coordination and communication a nightmare, especially in emergency response scenarios. CVE solved this by giving each known vulnerability a unique identifier, which everyone—vendors, researchers, defenders—could use to speak the same language.
How CVEs Became Integral to Detection and Correlation
At Network Security Wizards, we used CVE data in our Dragon intrusion detection system. CVEs helped correlate network attacks with known vulnerabilities at a high level. If an attack was aimed at a Linux exploit but the target was a Windows machine—or even a router—we could determine that the exploit would likely fail. That kind of event-to-vulnerability correlation was a game changer.
Screenshot from the animation on correlating intrusions with vulnerabilities.
Later, when I helped co-found Tenable Network Security, CVEs continued to be a key part of our strategy. Nessus, Tenable’s flagship product, used CVE identifiers to track and report on vulnerabilities across customer environments. CVEs weren’t just labels—they were the indexing backbone that allowed us to cross-reference our scan results with vendor advisories, patches, and threat intelligence reports.
Without CVEs, correlating vulnerability scanners, intrusion detection alerts, vendor bulletins, and known exploits would have been chaos.
The Evolving Ecosystem: From CVE to CPE, CWE, and Beyond
CVE was just the start. Over the past 15–20 years, we've seen the rise of related standards like:
CPE (Common Platform Enumeration) – So we can all call software by the same name
CWE (Common Weakness Enumeration) – To identify coding flaws, especially in custom apps
MITRE ATT&CK – A framework for understanding adversary behavior
XCCDF and SCAP – For standardized configuration auditing
All of these standards were designed to create an automated, interoperable, and actionable cybersecurity ecosystem. Unfortunately, we’ve never fully realized that dream. Much of the reason lies in the industry's shift toward cloud-first models, where traditional scanning and software inventory often fall short.
Gotchas: What Most People Miss About CVEs
Most people assume a CVE is created the moment a bug is discovered or disclosed. But that’s not how it works.
Let’s break down a vulnerability’s lifecycle:
It begins deep in the code, perhaps from a misused pointer or unchecked input.
It may persist for years, through multiple versions, never noticed.
Finally, someone finds it—maybe through tools like Ghidra or Hex-Rays—and submits it.
A CVE is only issued if the vulnerability is validated, assigned by a CNA, and made publicly referenceable. But many real-world issues never get a CVE, and some valid submissions are deferred due to scope, politics, or lack of clarity.
A Vulnerability Speaks: "I've Been Waiting"
A vulnerability, sitting between lines of code, speaks to a reverse engineer just after its been discovered.
To illustrate this, our team created a dramatized monologue from the point of view of a vulnerability:
“Oh, so you finally found me. Let me guess—Ghidra? Hex-Rays? Took you long enough. I’ve been here since commit 8F3B2D7. Just waiting.”
It’s a clever way of reminding people that vulnerabilities don’t appear out of nowhere. They are baked into the code, often unintentionally, and wait to be discovered. They survive version updates, vendor changes, and even security audits.
Sometimes, when finally discovered, they may get a flashy CVE and public writeup. Other times, they’re quietly patched or forgotten.
Don’t Forget the KEV
While we’re talking standards, we’d be remiss not to mention the KEV (Known Exploited Vulnerabilities) catalog from CISA. This resource tracks vulnerabilities that are actively being exploited and is a great tool for prioritization.
In one of our previous Gula Tech Adventures videos, we used KEV data to compare the vulnerability rates of Windows, Linux, and mobile operating systems when analyzing the safest platform to run Signal on.
Pro tip: If you're looking to prioritize patches, look at the KEV list before anything else. Exploited bugs should always be patched first.
Is CVE Still Relevant in 2025?
So, is the CVE system still relevant in 2025?
Yes—but its role is shifting, and our expectations need to evolve. CVEs continue to serve as a critical reference point for patching, detection, and coordination across cybersecurity teams, vendors, and platforms. They give us a shared language to talk about risk, and help link together everything from threat intel and SIEM alerts to compliance frameworks and vulnerability scans.
But here’s the hard truth: The way attackers are breaching organizations today often bypasses everything CVEs were built to defend.
We’ve spent the last 20 years investing in endpoint protection, perimeter firewalls, vulnerability scans, and patch management. All of that still matters—but serious attackers, especially nation-states and advanced criminal groups, are skipping past traditional network controls entirely.
Instead, they’re:
Stealing cloud API keys
Exfiltrating tokens, credentials, and configuration files
Abusing cloud misconfigurations and weak identity systems
Living off the land inside SaaS apps and collaboration platforms
They’re not looking for a buffer overflow in your web server anymore—they’re logging into your cloud dashboard like they belong there.
This doesn’t make CVEs obsolete. But it does mean that relying solely on CVE-driven scanning or patching as a security strategy is dangerously incomplete.
If we’re going to treat cybersecurity as a profession—as something critical to national and economic security—then CVEs need to exist alongside controls that focus on identity, permissions, and cloud-native risks. The CVE program must evolve to include new classes of vulnerabilities, including cloud misconfigurations, insecure defaults, and leaked secrets.
As we move forward, we should tie the concept of “vulnerability” to outcomes that actually matter: data theft, infrastructure compromise, and public safety. That means prioritizing not just what code has a bug, but how attackers are getting to the data we care about—and stopping them.
So yes, CVE is still relevant—but in 2025, we need to widen the aperture and update the way we define, track, and respond to risk.
Final Thoughts: More Than Just a Number
CVE isn’t just about cataloging bugs. It’s a foundation for how we share knowledge and respond to risk in cybersecurity.
As the industry professionalizes, CVEs should evolve from “just a number” to being tied to real-world outcomes—like keeping the power grid online or hospitals safe from ransomware. That’s the vision we should be pushing toward.
Until then, keep speaking CVE. It’s still the closest thing we’ve got to a universal language in cyber.