Home
Unchained
Security Blog

How CVEs slow down developer productivity

John Speed Meyers, Manager at Chainguard Labs

The Pain of CVEs

No (sane) software developer or security engineer wakes up excited to deal with CVEs. They're tedious, break your focus, and can feel like a waste of time. But it’s the sad reality that either for compliance or security reasons, reducing known software vulnerabilities (or CVEs) has become part of the day-to-day job of software professionals. That's why developers and security teams are increasingly frustrated by the sheer amount of time and effort sunk into CVE management.

My own past research on CVE management and containers reveals both a substantial “time” cost and negative effects on staff morale. In essence, companies that build or operate containers are spending thousands of hours annually on CVE triage, forcing skilled developers to chase false positives and piece together confusing information instead of building the next killer app.

Problem 1: Time drain

The number of hours lost to CVE management is staggering. In Chainguard's The True Cost of CVE Management in Containers report, we interviewed companies estimated anywhere from hundreds to thousands of hours spent annually on tasks related to identifying, triaging, and fixing vulnerabilities. One company even dedicated the equivalent of 10 full-time employees to this work every year.

But where does all this time go? The problem is multifaceted:

  • False alarms:

    Security scanners often flag vulnerabilities that are irrelevant to your specific container, leading to wasted time confirming or dismissing the alerts.

  • Confusing information:

    Sifting through CVE descriptions, deciphering severity ratings, and finding viable fixes can be a scavenger hunt. Many exasperated developers end up with dozens of browser tabs open just to understand a single vulnerability.

  • Testing and dependency headaches:

    Even minor updates to address a CVE can trigger time-consuming regression testing. Fears of breaking the application make developers hesitant, leading to even longer delays.

Problem 2: Beyond time

The frustrations of CVE management extend beyond the hours spent chasing vulnerabilities. The constant firefighting erodes developer productivity, damages team collaboration, and potentially increases the risk of a successful attack.

  • Morale drain:

    The constant churn of CVEs — especially false positives — is demoralizing. In our annual

    report on CISO and developer trends in software supply chain security, a third of the surveyed software developers expressed the belief that false positives from software composition analysis tools are a major obstacle to improved software supply chain security.

  • Container security disconnect:

    A stark gap exists between developer and CISO perceptions, as surfaced by the same report. Only 43% of developers believe CISOs understand the risk of container images, while just 50% of CISOs rate developers as "very security-conscious." This disconnect undermines collaboration and increases vulnerability risk.

  • The risk of exploit chains:

    Attackers don't just exploit major vulnerabilities. They can chain together a series of seemingly minor CVEs to compromise an organization. This means even low-severity vulnerabilities need attention, overwhelming developers further.

Can DIY OS package updates help?

Faced with the massive burden of CVEs, it's logical to think that keeping your container images up-to-date with the latest OS packages would significantly reduce risk. After all, shouldn't those updates include fixes for known vulnerabilities? Unfortunately, as Chainguard's research in the Zero CVE Challenge blog post revealed, the reality is far more disappointing.

Even after updating popular Docker Hub images, the average CVE count dropped by less than six percent. Why? Because even the latest official OS packages contain a vast number of pre-existing CVEs. This forces teams into that same cycle of chasing CVEs, even after what should, in theory, be a simple fix.

Pre-built, hardened container images are better

The struggle with CVEs highlights a need for a different approach. Continuously patching CVEs as they emerge is important, but there's a better way to lighten the load upfront.

Chainguard Images are built to have low-to-no CVEs. They are designed to be minimal: they use only what is necessary to build or run an application. These Images, when a component version is available, are updated rapidly. The result is that developers can begin working with minimal, hardened containers at the start of their development, which drastically reduces vulnerability counts from day one. This translates to:

  • Time back for innovation:

    Developers spend more time building product innovation that generates revenue and satisfies customers and users, not chasing noisy false positives or navigating confusing CVE data.

  • Stronger security posture:

    Minimizing vulnerabilities significantly reduces the attack surface, improving overall an organization’s security posture.

  • Better together dev and security teams:

    Fewer vulnerabilities can mean less friction between security and development teams, fostering better collaboration on the most important work for their business. Hear from GitGuardian about their experience.

Build faster, safer: Discover Chainguard Images

Ready to break free from the CVE time sink? Explore Chainguard Images and discover how to stop wasting time and start building more secure software. Reach out to our team today to get started.

Share

Ready to Lock Down Your Supply Chain?

Talk to our customer obsessed, community-driven team.

Get Started