Cure Your ‘Zero CVE’ Hangover With Transparency

The pursuit of “zero CVEs” (common vulnerabilities and exposures) in software is not only unattainable: It diverts critical resources from real-world security challenges. Leaders who have adopted the zero-CVEs tagline are finding themselves with a proverbial hangover from their complicated and fragile mitigation strategy. This obscures a true understanding of your security posture, and leaves you with a foggy, if not incomplete, picture of how vulnerable you really are.

The best way to avoid this hangover is by adopting a transparent approach to your vulnerability management situation.

With Enterprise Security, Ignorance Is Not Bliss

While organizations are adopting the zero-CVE mantra as a security pursuit, it is essentially a noise-reduction mechanism that only highlights CVEs that have a fix. This is because the zero-CVE philosophy mostly hinges on the idea that only those CVEs with patches are counted. You can see how this is dangerous: In enterprise security, context is critical, and ignorance is far from bliss.

Modern software applications are inherently complex. They are composed of hundreds of components, each leveraging countless open source libraries. For instance, a single application with a few hundred microservices could contain thousands of distinct dependencies, each a potential source of vulnerabilities. New CVEs are discovered daily, meaning achieving and maintaining a zero-CVE state for any significant software system is statistically impossible. In a large enterprise, this can involve tracking millions of entries weekly.

The zero-CVEs concept has several critical shortcomings:

• Lack of context: Not all vulnerabilities pose the same risk. The zero-CVE approach often fails to consider the operational environment or exploitability of a vulnerability in the real world. A high-severity CVE in a component that is not exposed nor used in a critical path might be less risky than a lower-severity one with easy exploitability.
• It breaks the “trust but verify” social contract: “Trust but verify” works only when the vendor discloses the true nature of the CVEs in their software. Many software vendors disclose CVEs only in the proprietary parts of their software, so enterprises must rely on third parties to verify the security of the software’s open source components. Vendors proclaiming a zero-CVE message typically do not report a vulnerability until a patch is available, leaving customers defenseless until a fix is developed, reported and applied. This lack of transparency fundamentally breaks the inherent contract in the “trust but verify” model and sets a dangerous precedent.
• It hinders strategic security work: When security teams are mired in the Sisyphean task of triaging millions of CVEs each week, they have no time to focus on strategic security initiatives, such as identifying real business risks, building secure-by-design applications, or implementing controls that prevent entire classes of vulnerabilities (e.g., input validation to stop SQL injections).

Security Through Obscurity Is Not Security

A more pragmatic and effective approach to security and vulnerability management embraces transparency and a platform-centric strategy. Organizations need to acknowledge the continuous discovery of vulnerabilities and shift their focus from eliminating all CVEs to managing real, contextualized risks with continuous security and upgrades. This will ultimately help security leaders and platform engineers better understand their security posture and improve their response time to critical vulnerabilities and software failures.

You can rethink your approach to security without falling prey to the promise of zero CVEs. Here are some ways you can start shifting your security strategy to avoid the zero-CVE hangover:

• Maintain transparent upstream partnerships: Build trust with software providers who are honest about all vulnerabilities in their products, including those in underlying open source components. This transparency provides a single, trusted source of truth, reducing the need for costly and redundant third-party scans.
• Take a platform approach for standardization and control: Utilizing platforms allows for a standardized environment where security and compliance postures are preset and consistent across applications. This significantly reduces the attack surface and centralizes controls, allowing teams to focus on the most critical risks rather than millions of disparate vulnerabilities.
• Focus on application-specific risks: By offloading the management of platform-level vulnerabilities to a trusted platform provider, application teams can concentrate on the vulnerabilities introduced by their own code, dependencies and business logic (e.g., business logic flaws). This allows for a proactive, “secure by design,” risk-based business-centric approach.

The zero-CVE mindset is a fallacy that has crippled effective security programs. The path forward requires a shift towards transparency, trust and a platform-based approach that enables organizations to efficiently identify, prioritize and mitigate the most impactful risks, rather than chasing an impossible target.