Excluding Zero-Days from Vulnerability Management Discussions

When people in security talk about risk, the phrase “zero-day” tends to dominate the minds of a lot of security practitioners. It has an aura of danger, the idea of an attacker exploiting a flaw we don’t yet know exists.

‍

It’s scary.

‍

It is the kind of phrase that makes headlines and attracts attention from both the security community and the press. But the reality of how it fits in with a conversation around vulnerability management is more complicated, and in practice, zero-day exploits have very little to do with the purpose or function of vulnerability management programs.

‍

To be absolutely clear here, when I say zero-day, I really mean that no one, not the vendor, not anyone, has knowledge of its existence until the adversary uses it. No time has elapsed since the attacker has used it. This is happening in real-time, as we speak, and the vendors and VM players are scrambling to get a signature and a patch out to customers.

‍

Consider the numbers

‍

Google’s Threat Analysis Group and Mandiant tracked 97 zero-day vulnerabilities exploited in the wild in 2023. The year before, that figure was 62. In 2021, which still stands as the high-water mark, it was 106. In 2024, the number fell again to 75. Since 2014, Project Zero has cataloged only a few hundred incidents. That might sound like a lot, but given the scale of enterprise IT and the volume of known vulnerabilities disclosed every single year, it is statistically insignificant.

‍

Even more important to this discussion is where these exploits occur.

‍

The majority of zero-day attacks used in the wild, according to Project Zero, focus on consumer-facing software: browsers, mobile devices, messaging clients, and consumer operating systems. Said another way, it’s largely client-side code, not server-side and not remotely accessible. Attackers, using this form of zero-day, target platforms that touch billions of end-users, not specifically enterprise infrastructure. It’s random who gets compromised in many cases. 

‍

While corporate exploitation does happen, it usually occurs in smaller numbers, often focused on espionage or surveillance operations. When zero-days do affect end-users, they tend to be deployed through techniques like drive-by downloads or poisoned attachments that deliver commodity malware such as Zeus or Osiris. These types of issues also have the property of being quickly patched in many cases, because end-users tend to use software that silently and automatically updates. So, the vast majority of vulnerabilities of this category are fixed in short order.

‍

Client-side zero-day is disruptive to individuals, but they are not the drivers of business losses at scale. If you switch to talking about known non-zero-day client-side vulnerabilities that are dropped via social engineering, or other forms of drive-by, it expands somewhat, but credential stuffing and brute force also comprises a great risk. In sum, all of that represents about half of the losses a company might risk facing. But the losses almost never come from client-side zero-day. And it also doesn’t come from server-side zero-day.

If you want to pick one category of risk that comprises the largest single category of risk, that crown lays on the head of known vulnerabilities in server-side CVE vulnerabilities that can be attacked by a remote, unauthenticated adversary.

‍

This is where vulnerability management fits in. VM is designed to scan for known vulnerabilities; issues that have been: cataloged, assigned CVEs, and analyzed for severity and exploitability. VM is ideally for identifying flaws that attackers are statistically most likely to use, because those flaws already exist in exploit kits and are sold and re-used by groups around the globe. If we expect VM systems to find net-new vulnerabilities, we are asking them to do something entirely different, closer to static or dynamic analysis in web applications, or application fuzzing. Those at least have a chance of finding novel flaws.

‍

That is not their design.

‍

When businesses suffer real losses, they are usually traced back to unpatched known vulnerabilities, not exotic zero-days. Attackers overwhelmingly prefer the path of least resistance, and in practice, that means exploiting what has already been disclosed but left unresolved. The sheer prevalence of known, unpatched issues explains why vulnerability management is not only relevant but necessary.

‍

None of this means zero-days can be ignored. They are a real risk, but they require a different defensive posture. Strong multi-factor authentication reduces the impact of credential theft. Backups and robust disaster recovery plans ensure that a breach is not catastrophic. Detection, isolation, and response programs help contain damage before it spreads by reducing dwell time of the adversary. These are systemic mitigations that belong in a different category than vulnerability management; they are important, but different.

‍

Can VM find zero-days after they have become public, when they are more like one-days or N-days? Sure, of course. That is when they move from the category of zero-day to a known vulnerability, and if they are being actively exploited they move to something called a KEV: a known exploited vulnerability. In that context, sure, a vulnerability management solution can and should be of use, but the vulnerability in question is not a zero-day anymore.

‍

Zero-day exploits may be exciting to talk about, but they are not what vulnerability management is for. Conflating the two only muddies the conversation and misleads organizations about how to measure risk. Vulnerability management is about protecting against what is known and measurable. Zero-day requires a different set of tools.