Migrating to Chainguard Images: less CVEs for safer container runtimes

Software supply chain attacks have become common in the industry lately, with the latest episode featuring the infamous CVE-202403904 and the xz’s backdoors.

Whether malicious or unintentional, a CVE can pose as severe risk to organizations relying on a piece of affected software. The CVE database has over 200.000 entries and it just scratches the surface, since unreported exploitable vulnerabilities (a.k.a. zero-days) are a fairly common occurrence in the hacking scene.

For a long time, this was not a developer’s concern. But with the explosion of open source third-party software dependencies, it is virtually impossible to keep track and know everything that is included within a software artifact, whether we’re talking about a single package or a whole operating system. Just as in other industries, a compromise in any point of your supply chain represents an issue that may be exploited by bad actors.

Less CVEs for safer container runtimes

It is a no-brainer that using a container image with less CVEs is better for security. Reducing the surface for attack has proven to be an effective way of creating safer container runtimes.

Consider the php:alpine image, which is known for being a smaller image when compared to Debian and Ubuntu variants:

Screenshot shows output from the command "grype php:alpine", showing a total of 20 medium severity and 1 high severity CVEs.

Now let’s have a look at this image’s Chainguard equivalent, the cgr.dev/chainguard/php:latest image:

Screenshot shows output from the command "grype cgr.dev/chainguard/php", showing 1 medium severity and 1 high severity CVEs.

It’s worth noting that these numbers fluctuate naturally as new CVEs come out and new patches are available by package vendors. The following graph shows a 30-day comparison between php:latest and cgr.dev/chainguard/php, for another perspective (live version available here):

Screenshot shows month comparison between php:latest and cgr.dev/chainguard/php

So how is this possible? We could say the secret sauce of Chainguard Images is a drastically reduced surface for attack, but that is just one of the many ingredients that make these images stand out in terms of container security. Provenance attestation is another important feature that provides a way to verify the image comes from where it should.

Resources to Learn More

The Migrating Dockerfiles to Chainguard Images guide has a high-level overview with a couple examples showing how you can migrate from other base images to Chainguard Images. We have also a dedicated PHP Migration Guide you can use as reference when migrating PHP Dockerfiles to Chainguard Images.

If you’d prefer a more hands-on experience, I’ll be presenting a Learning Labs workshop next week (Tuesday April 23, 12PM ET / 6PM CEST) about this topic. We’ll talk a bit about CVEs, software supply chain security, and then I’ll dive into some live demos showing all you need to know for a streamlined migration process. Hope to see you there! You can register here to save a spot.


Discover more from Coursity

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *

Discover more from Coursity

Subscribe now to keep reading and get access to the full archive.

Continue reading

Scroll to Top