Why zero CVEs makes zero sense

If a vendor tells you it can enable zero CVEs (Common Vulnerabilities and Exposures), you should run, not walk, away. Not only is it impossible to get to zero CVEs, there’s really no need to even try. In fact, the very act of trying to achieve zero CVEs could actually increase vulnerability if the security big picture is ignored.

“Zero CVEs” is a term being bandied about as cybersecurity nirvana — the notion that software has no identified security vulnerabilities. Setting a goal of zero CVEs has gained traction lately, in part because of a trend toward stricter regulations like FEDramp and in part because some technology providers are saying they can achieve it.

You may be reading this and thinking, “What’s wrong with at least trying to eliminate CVEs? If it’s a known vulnerability, shouldn’t we always try to remediate?”

Yes and no, because engineering is a zero-sum game. There are always tradeoffs.

Chasing CVEs

There are always tradeoffs because, according to the CVE Numbering Authority operational rules, a CVE ID indicates that a software or hardware vendor has acknowledged a bug’s existence and confirms that the bug negatively impacts security. It can also indicate that the reporter of the flaw has a shared vulnerability report that demonstrates both the negative impact of the bug and that it violates the security policy of the affected system.

In other words, the bug is real and recognized, so, in theory, it would make sense to patch it.

However, there is a fundamental problem with the zero CVEs concept in practice. Namely, the only way to get close to zero CVEs at scale is to always upgrade to the latest upstream code. This gets you the latest security patches, but also brings with it new features, new bugs, new regressions, new incompatibilities, configuration changes, etc. In other words, we have to recognize that any code change can further introduce new vulnerabilities (or instabilities) that may be worse than the vulnerability corrected.

The issue is that not every single software flaw is a threat (or a serious threat) to security, especially given the rising tide of CVEs. For example, there were about 30,000 CVEs recorded in 2023, but nearly 40,000 in 2024.

There are many variables feeding this CVE inflation. The list includes increases in the number of programmers writing code, AI code generators helping them, the sheer amount of new code being written, an increase in the complexity of that code, and incentives for both security researchers as well as hackers. For example, students and security researchers are incentivized to find and report CVEs by financial, academic, and personal-brand-based rewards. Worse, with the AI wars coming, we can expect discovery of new CVEs to increase rapidly. An arms race is coming where AI will assist in discovery of new CVEs as well as patching them. The ultimate outcome could be absurd code churn. Some upstream projects even refuse to accept bugs found by AI, effectively creating a denial of service attack on developers.

Add to all of this the strong incentive for security scanning software vendors to show “something wrong” (e.g. CVEs) with the software they’re scanning when they’re selling their products to prospective customers. If the scanner reveals more problems, it must be better software, right? Obviously, that’s not true. It’s a perverse demonstration of value.

The entire ecosystem is driven to discover and highlight more CVEs, even when risk might be very low.

An exercise in futility

There are other issues that make CVE chasing an unproductive endeavor. CVEs sometimes lack sufficient detail or are based on incomplete information, which can lead to inaccurate scoring or misinterpretation of the risk. CVE risk also changes over time. For example, when active exploitation becomes known, other vulnerabilities may exist that make exploiting another flaw easier. On the flip side, many CVEs are impossible to exploit remotely, and sometimes software can be configured to make the CVE irrelevant.

In addition, CVEs don’t account for how impactful a flaw may be based on the type of code being exploited. Shell programs, daemons, or libraries each incur different risk to an organization, and they’re not equal. CVEs also don’t figure in the presence of compensating controls (defense in depth), the criticality of affected systems, or exploitability in a specific environment.

All of this is not to underestimate the importance of CVEs. Indeed, CVE-2021-44228 was a doozy — the dreaded Log4j bug had been lurking in the code since 2013, but wasn’t discovered until 2021. During this eight year period, susceptible versions of Log4j became ubiquitous, making the logging library a tempting target for exploitation. And, of course, many other CVEs are indicators of similarly high risk, considering all factors.

But… with all of this security infrastructure and industry inertia to discover and highlight new CVEs, not a single vendor found the Log4j vulnerability for years and years. It’s a perfect example of how the concept of zero CVEs provides a false sense of security. There are always undiscovered CVEs lurking in your environment. Getting distracted by low priority CVEs while not implementing defense in depth is a huge mistake.

Focus on the broader defense

So, yes, patching reported vulnerabilities is important, but no single security policy or technical control can protect against the diverse threats facing organizations today. Patching is just one layer in a broader defense architecture.

Rather than chasing low priority CVEs, which can’t be exploited, organizations should focus on defense in depth. Organizations should ensure that their infrastructure is set up so that undiscovered vulnerabilities that create real risk cannot be exploited — and so that, if they are exploited, the damage will be minimized or mitigated by other technical controls.

Indeed, chasing and fixing CVEs is not what “hardening” means. True hardening means implementing a set of security controls to minimize or eliminate risk. Controls like SELinux, hardened binaries (RELRO, PIE, etc.), and kernel security features can mitigate the impact of vulnerabilities, sometimes rendering exploits ineffective. For example, exploitation of a runc vulnerability (CVE-2019-5736) which could compromise entire systems was blocked by SELinux.

Best practices are key. For example, with containers specifically, you have to account for the platform and best practices for containerized deployments. Don’t run distinct services (ticket system, DNS, public web server, and wiki) in a single container. Don’t run SSHD to allow shell access. Ensure the platform is hardened to prevent shell access coming from the platform. Consider, for example, whether a vulnerability in Python really matters if your sole application is a Java-based web stack.

There’s also the fact that identity-based and social engineering attacks can bypass technical vulnerabilities entirely. Attackers commonly target account credentials, API keys, session cookies, and tokens, exploiting weak authentication or tricking insiders into granting access. And then there’s the threat of malicious insiders using legitimate access to steal data or otherwise compromise systems and the organization.

Attackers also target associated systems and infrastructure, such as network-attached storage, backup systems, managed endpoints, domain controllers, or even software at end of life. These systems can serve as entry or pivot points that enable attackers to gain entry into otherwise secure environments. Misconfigurations are another leading cause of breaches that can provide access to even the best-patched systems.

Develop a security plan

No amount of CVE chasing or patching — or even getting to zero CVEs — will prevent compromise due to these threats. In fact, software and container images can still be insecure even if your dashboard shows that there are zero CVEs. Worse, zero CVEs could provide you with a false sense of security that results in less vigilance or under-investment in more practical areas. There are always undiscovered vulnerabilities and some of them are worse than the ones you know about.

The zero CVEs promise is about chasing upstream patches as quickly as possible, not about fundamentally eliminating risk. Counting CVEs alone is naive and leads to “bike shedding.” It’s easy to count things, and then get obsessed with that process. Risk-based security, instead of checking boxes on a security policy document, is much more effective, balancing “getting stuff done” with mitigating risk.

The time and money organizations dedicate to achieving zero CVEs would be better spent in developing a security plan that is about prioritization and context. Defense in depth, robust identity and access management, secure configurations, and runtime protections are all critical components. Chasing the goal of zero CVEs may tick off some compliance check boxes, but it will not fully address the evolving and holistic threats to enterprise security.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.