Why images with zero-known CVEs are worth it

Adrian Mouat, Staff DevRel Engineer
  •  
January 26, 2024

The majority of CVEs (common vulnerabilities and exposures) reported by scanners may not always be a problem in reality; some are often false positives or can't be exploited as there is no way for an attacker to execute that code path. Because of this, I occasionally hear arguments that the usefulness of scanners is limited and we should not spend so much time worrying about CVEs. In other words, the juice (knowing you are not vulnerable to known CVEs) is not worth the squeeze (running scanners and investigating the results).

While I have some sympathy for this view, I would point to some cases where the effects of ignoring CVEs has been devastating and why we need to challenge this industry perception.

The impact of ignoring CVEs

All CVEs are given an innocuous sounding number. CVE-2017-5638 was a vulnerability in Apache Struts, a Java MVC framework, which allowed remote code execution via HTTP headers. The nature of this vulnerability meant that it was simple for hackers to scan for vulnerable systems and exploit them, and one of the exploited organizations was Equifax. The exploit led to the private financial data of almost 150 million U.S. citizens and over 15 million UK citizens being compromised — one of largest data breaches in history. And it can be directly traced back to a known CVE.

The undisputed heavyweight of all CVEs is CVE-2021-44228 — better known as Log4Shell and once described as "the single biggest, most critical vulnerability ever." The Log4j software was — and is — so widespread that nearly all large organizations are running it somewhere. Millions of devices were affected, as a lot of IoT (internet of things) software such as TVs turned out to be running Log4j. The big problem that ops and security staff had was identifying everywhere Log4j was used — it was so prevalent that it took weeks in some cases to find all the instances.

In other instances, CVEs have directly allowed attackers access to systems and have cost organizations millions in reputational loss, lawsuits, and ransomware.

So, even if the vast majority of CVEs are not a cause for security ruin, the small percentage that are can still have a costly and crippling effect. The juice is most definitely worth the squeeze.

Getting to zero CVEs

I also bring some good news: it is not as hard as it may seem to get to zero-known CVEs. Our mission at Chainguard is to produce secure container images with as few vulnerabilities as possible, and we're the experts at it. The easiest way to benefit from our work is to use Chainguard Images; we have images for common open-source software such as nginx, Redis and MariaDB as well as base images like JDK and node that can be used with Dockerfiles to build your own images.

Learn more!

If you'd like to learn more about how we build images with low-to-zero known vulnerabilities, please watch my full presentation from Cloud Native Rejekts NA 2023 below. If you’d like to learn more about our Chainguard Images solution and how we can help you eliminate CVEs in the open source software you consume, reach out to our team. 

You can find me on X at @adrianmouat if you have any questions.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Don’t break the chain – secure your supply chain today!

Security

Why images with zero-known CVEs are worth it

Adrian Mouat, Staff DevRel Engineer
January 26, 2024
copied

The majority of CVEs (common vulnerabilities and exposures) reported by scanners may not always be a problem in reality; some are often false positives or can't be exploited as there is no way for an attacker to execute that code path. Because of this, I occasionally hear arguments that the usefulness of scanners is limited and we should not spend so much time worrying about CVEs. In other words, the juice (knowing you are not vulnerable to known CVEs) is not worth the squeeze (running scanners and investigating the results).

While I have some sympathy for this view, I would point to some cases where the effects of ignoring CVEs has been devastating and why we need to challenge this industry perception.

The impact of ignoring CVEs

All CVEs are given an innocuous sounding number. CVE-2017-5638 was a vulnerability in Apache Struts, a Java MVC framework, which allowed remote code execution via HTTP headers. The nature of this vulnerability meant that it was simple for hackers to scan for vulnerable systems and exploit them, and one of the exploited organizations was Equifax. The exploit led to the private financial data of almost 150 million U.S. citizens and over 15 million UK citizens being compromised — one of largest data breaches in history. And it can be directly traced back to a known CVE.

The undisputed heavyweight of all CVEs is CVE-2021-44228 — better known as Log4Shell and once described as "the single biggest, most critical vulnerability ever." The Log4j software was — and is — so widespread that nearly all large organizations are running it somewhere. Millions of devices were affected, as a lot of IoT (internet of things) software such as TVs turned out to be running Log4j. The big problem that ops and security staff had was identifying everywhere Log4j was used — it was so prevalent that it took weeks in some cases to find all the instances.

In other instances, CVEs have directly allowed attackers access to systems and have cost organizations millions in reputational loss, lawsuits, and ransomware.

So, even if the vast majority of CVEs are not a cause for security ruin, the small percentage that are can still have a costly and crippling effect. The juice is most definitely worth the squeeze.

Getting to zero CVEs

I also bring some good news: it is not as hard as it may seem to get to zero-known CVEs. Our mission at Chainguard is to produce secure container images with as few vulnerabilities as possible, and we're the experts at it. The easiest way to benefit from our work is to use Chainguard Images; we have images for common open-source software such as nginx, Redis and MariaDB as well as base images like JDK and node that can be used with Dockerfiles to build your own images.

Learn more!

If you'd like to learn more about how we build images with low-to-zero known vulnerabilities, please watch my full presentation from Cloud Native Rejekts NA 2023 below. If you’d like to learn more about our Chainguard Images solution and how we can help you eliminate CVEs in the open source software you consume, reach out to our team. 

You can find me on X at @adrianmouat if you have any questions.

Related articles

Ready to lock down your supply chain?

Talk to our customer obsessed, community-driven team.