It all started with a commit: Celebrating 6 years of Distroless

Big things all start the same way - with an initial commit, and the distroless project was no different. Six years ago today, we kicked off the original Distroless project with a goal to provide a more secure and efficient way to package and run software in containers by removing all non-essential components from the base image.

We prototyped build tooling based on the Bazel toolchain to directly generate Docker images from Debian packages, and cranked out the first few language runtimes for Python, Java, C++ and Go over the next several weeks. A few months later, Matt presented the concept of distroless containers at SwampUp, and the project started to gain traction in the containerization community.

Distroless was never a formally staffed or funded project at Google, so its popularity grew organically over the next several years, culminating when the upstream Kubernetes project announced it was adopting it as the default base image for containerized workloads with the KEP-1729 proposal. The rationale for using Distroless in Kubernetes was to dramatically reduce the toil around vulnerability management for the release engineering team.

Distroless meet software supply chain security

Minimal containers help with vulnerability management, but that’s only one piece of the supply chain security puzzle. At the time, attacks on build systems and package distribution networks were on the rise, so we shifted focus and created the Sigstore project to help provide traceability through digital signatures for the open source community. In May 2021, Sigstore was integrated into distroless, adding an additional layer of security to the already minimal container images – making it easier for developers to sign their containers and verify their authenticity.

‍

Since then, distroless containers have become a category of their own, with other vendors producing similar minimal container images. Some of our surveys and data analysis have shown that distroless containers represent between 10-15% of all containerized workloads, and its adoption by Kubernetes means it's running in almost all clusters around the world.

‍

If you asked us if we thought this type of adoption and usage was going to be possible after pushing that first commit we both would have laughed at you.

Improving distroless with Chainguard Images

While the original distroless project provided a great foundation, we started to run into limitations with its architecture caused by the Bazel toolchain and reliance on Debian as an upstream distribution.

‍

We knew we could build something better and so we started Chainguard to do just that.

In late 2022, we released a new Linux (un)distribution called Wolfi, which takes the concept of distroless to the next level by building all packages from source. Wolfi is designed natively for containerized, cloud-native workloads, and allows for fine-grained package management, flexible version selection, built-in SBOMs, and a zero-known CVE target through constant patching.

‍

For example, if you try using the original approach to distroless to build a git image you are going to run into the tedious process of manually chasing dependencies which will take you several hours. How do we know that? Because we tried to do it and gave up. With our next-gen approach, it took us a whole five minutes to create the git image. This approach scales better than the original and is much more sustainable as a result.

‍

As the industry matures and container adoption becomes ubiquitous, containers built with the distroless framework are best positioned to support and secure the next generation of container and cloud native application development. Their overall rise in prominence might feel fast to some, but for those of us working on them day to day, these six years have felt like a lifetime.

‍

As with the evolution of anything, the first iteration is never going to be the best iteration. It's fun to look back and see how far our 20% project has come, but what really excites us is looking ahead to the future and where we are headed.

‍

If you want to see upwards of a 97.6% reduction in CVEs with more security built in by default start using Chainguard Images today at github.com/chainguard-images.

‍

Chainguard Images are now available for over 65+ images including Bazel, curl, Git, Go, Jenkins, Postgres, Ruby and Python. If you’re interested in support contracts, SLAs for vulnerabilities, FIPS-enabled images, or support for custom images or older versions, please reach out.

‍

We are always looking for ways to improve our end user experience. If you have feedback or would like to submit a support issue you can reach out to us directly or file it here.

‍

P.S. Honorary birthday shout out to LetsEncrypt GA which turns 7 today!