A Better Way to Consume Third-Party Applications

Third-party applications, such as popular databases (MySQL, Postgres, Clickhouse, etc.), servers (NGINX, Envoy, etc), and developer tools (ArgoCD, Spark, Prometheus, etc.), are essential building blocks for modern software development. Traditionally, developers either manually install these applications on top of a full Linux OS, or download a container image from public internet sources to acquire the application. However, this introduces a number of challenges:

1. Manually installing third-party application packages from untrusted internet sources often reverses the hardening effort conducted by platform teams. 

2. Open source third-party application images from registries like Docker are based on unhardened, kitchen sink distributions, which introduces a heavy volume of CVEs and expands your container’s already large attack surface.

And in both scenarios, developers lack control over the application dependency tree, meaning they either 1) are entirely beholden to upstream maintainers for issues patches, or 2) are taking on the burden of forking and patching third-party code themselves, driving further complexity.

In short, the traditional approach to consuming third-party application images is fragile and highlights the pressing need for a better solution. One that enables developers to pull all the applications they need – safely, securely, and scalably from the start. At Chainguard, we’re solving this problem with our Application Images, a suite of over 1,100 container images that are built entirely from source, are minimal, and designed to reduce your container attack surface. And our application images are simple to use – developers can drop them straight into their existing development stacks and keep moving.

To better illustrate the benefits of Chainguard’s Application Images, let’s get deeper into the status quo and the challenges with it.

Hardened in the Front, CVEs in the Back

Platform teams, the unsung heroes of modern DevOps best practices, often spend tremendous effort on hardening traditional base OS distributions. At Chainguard, we often refer to these distros as “kitchen sink” operating systems because they have been built for breadth, supporting laptops, servers, VMs, and more; however, these distros are generally not optimized for containers and cloud-native development because they 1) include excess components not required for building and running a container (broadening the attack surface) and 2) are delivered in frozen, “stable” releases that inhibit the ability of maintainers to deploy every software update and CVE fix. As a result, platform teams must do the hardening work themselves to ensure that developers can build applications from a safer, more secure foundation.

Third-party applications are where this delicate balance begins to break. Once that base OS is distributed downstream, we’ve heard from customers that application developers will typically manually install application components or layer open source application images onto the base image from untrusted sources – thereby undoing the platform team’s hard work.

While this approach is convenient, it drives numerous bad outcomes for platform engineers and application developers:

• Bloated Containers: Adding additional packages to the base OS, either manually or via kitchen sink application images, means a larger attack surface to defend.

• Lack of Control: Developers lack control over the application dependency tree, meaning they must either rely on upstream for patching, or manually patch images themselves, thereby taking on the complexity of maintaining third-party code. 

• Maintenance and Overhead: Should engineering decide to manage the third-party application code, they run the further risk of breakage when pushing patches and integrating applications into their dev stack. 

These challenges are true even for open source images for popular third-party applications like Airflow. Below is an illustrative example of Airflow, whose open source image contains 79 CVEs (including 15 critical/high CVEs) at an image size of 405MB and 612 packages.

Chainguard’s Modern Solution: Purpose-Specific, Minimal Application Images

To solve these challenges for our customers, Chainguard has built over 1,100 purpose-specific application images from source in a minimal fashion, thus eliminating attack surface and CVEs. And importantly, these images are simple to drop into your existing development stack and get moving quickly, as Chainguard takes on the burden of image management and CVE remediation so you don’t have to. Like our base images, Chainguard’s application images include only the components required to build and run your applications, with fully transparent attestation in the form of full build-time SBOMs and code signatures via Sigstore.

To demonstrate this point, take for example Chainguard’s Airflow image, which is illustrated below. The Chainguard Airflow image has only 6 CVEs, with only one critical, compared to the 79/15 split of the OSS image, and is significantly smaller at 270MB and 400 packages (vs. 405MB and 612 packages).

We see these similar outcomes – size and CVE reduction –  across the application images in our catalog, so you can focus on what matters: building the best possible experience for your customers. And we’re continuing to build up our catalog, helping our customers scale and deliver delightful products to their users.

Reducing Your Maintenance Burden

One of the most compelling advantages of the Chainguard model for third-party application images is the reduced maintenance burden required of developers, particularly when it comes to owning third-party application code. Traditional approaches to application image consumption requires engineering teams to take on responsibilities not only for their first-party application code, but also the base distro, its Linux dependencies, and all their app dependencies as well.

With Chainguard, customers can offload management and CVE remediation, with Chainguard taking ownership of the base Linux distribution, the Linux dependencies, and app dependencies as well. We highlight the shared responsibility between Chainguard and our customers in the diagram below:

Chainguard Application Images: The Modern Approach

Ready to uplevel your application development practices? Explore Chainguard’s application images today and reach out to learn more about how they can transform your workflows.