Drowning in CVEs and Cybersecurity Compliance Risks? There’s a Solution: Hardened Software Platforms

Mitigating common vulnerabilities and exposures (CVEs) is a critical responsibility for every organization that takes cybersecurity and compliance seriously. But it is also a daunting one because fixing CVEs can feel like trying to slay the Hydra (a monster in ancient Greek myth that grew two new heads every time it lost one): Every time your development team resolves one CVE, more crop up.

Indeed, given that new CVEs appear at the rate of about 108 every single day, and that 84 percent of organizations face high-risk vulnerabilities they have not yet addressed, stemming the never-ending CVE tide can be nigh impossible.

Fortunately, there’s a way to win this battle and, in the process, improve security and compliance outcomes. The trick is to stop playing the traditional CVE game by choosing software stacks that minimize the number of CVEs your business has to contend with in the first place. 

Here’s what that strategy means in practice, and why it has become essential for staying ahead of CVE challenges.

What are CVEs, and why do they matter for businesses?

To set the context, let’s start by discussing what CVEs are and why they matter for business leaders.

A CVE is a publicly documented cybersecurity vulnerability. The purpose of CVEs is to help organizations determine whether the software products they use are subject to security risks. CVEs also often include guidance on how to mitigate vulnerabilities.

So, tracking CVEs, and knowing how many unaddressed CVEs impact the software your business uses, is vital for preventing breaches. Leaving CVEs open is like opening the front door to your house and going on vacation: It’s an invitation for attackers to break into your systems and cause harm. And given that the average cost of a breach is about $4.44 million, according to IBM, the financial fallout of leaving vulnerabilities open can be substantial.

What’s more, mitigating CVEs quickly and efficiently is often essential from a compliance perspective. A growing number of regulatory frameworks, such as NIS2 and DORA, mandate that organizations have processes in place for responsible vulnerability management – which means that even if an open CVE doesn’t lead to a breach, it could cause regulatory violations and fines. Here again, the financial fallout can be grave. DORA, for instance, provides for fines of up to 5 million euros for security oversights, including CVE mismanagement.

The challenges of conventional CVE management

Staying on top of CVEs would be easy enough if organizations were impacted by only a handful of vulnerabilities at any given time.

But as noted above, this is rarely the case. For businesses that operate IT estates of any significant size, it’s common for hundreds or thousands of open CVEs to exist. And because new CVEs are disclosed every day, software development and cybersecurity teams often struggle to mitigate vulnerabilities faster than new ones arise.

Exacerbating this challenge is the fact that resolving CVEs can be a complex and time-consuming endeavor. If you’re lucky, a patch will be available that resolves the vulnerability linked to a CVE – but installing the patch takes time, especially because it’s often necessary to test the patch first to make sure it doesn’t cause compatibility problems for your applications. In other cases, there’s no patch at all, and your developers have to write one on their own – a process that could take days or weeks, depending on the complexity of the issue. It may also be necessary to recompile and redeploy software after patching, which adds even more time, risk and complexity to the process.

Given this complexity, it’s no surprise that the average software company spends about 1000 hours a year – or the equivalent of around 25 work weeks – just on vulnerability management. For some businesses, that number exceeds 10,000 hours.

In short, trying to mitigate CVEs by detecting and responding to each one is a recipe for burnout and failure. It worked in the days when fewer vulnerabilities existed, but not in a world where new CVEs appear at the rate of thousands per month.

A smarter approach to CVE mitigation

Instead of constantly chasing CVEs, businesses can build software stacks that fundamentally reduce their exposure to CVEs.

They can do this by selecting software platforms (such as operating systems or runtime environments) that meet two key criteria:

• They’re hardened, meaning they don’t include unnecessary components (such as software libraries or utilities that your business doesn’t actually use). The less code that exists in a platform, the lower the risk that CVEs will affect it.
• They’re managed by an upstream developer or vendor who mitigates CVEs on behalf of customers. This minimizes the number of CVEs to which your business is exposed – which goes far in meeting compliance obligations, while also improving cybersecurity outcomes. It also drastically reduces the burden placed on your own teams to manage CVEs.

Admittedly, this approach is not likely to reduce your CVE exposure account to zero. You’ll still need to identify and mitigate CVEs in any software applications that your organization develops or deploys on its own, without upstream assistance. But your business’s total CVE count will, in many cases, be a tiny fraction of the CVEs you’d need to manage if you also had to worry about vulnerabilities in your operating system, runtimes and so on.

How to choose a minimal-CVE platform

Finding and selecting these platforms can be challenging. Historically, many hardened platforms (such as minimalist container images, which businesses could use as the basis for creating their own containers) were open source products that were not professionally managed. They offered the benefit of minimal attack surfaces, but without the additional key assurance of professional upstream CVE mitigation. They also were not always able to generate reliable “proof” of software provenance or reproducibility because they hosted their code in publicly accessible repositories with limited access controls.

But that has changed over the past several years. A new market of established vendors has emerged for hardened software platforms. Businesses no longer have to choose between the unpredictability of purely open source solutions on the one hand, or the capriciousness of startups on the other.