Distroless: A zero vulnerability container

DevSecOps is a culture shift that aims to bake security in rapid release cycles.

As part of this DevSecOps practice, we scan containers for vulnerabilities in our CI/CD pipeline.

The development team manages issues found during this testing. Fixing these issues also stays within the development team.

So how do we ensure we have zero vulnerabilities during such testing.

Different developers may have different approaches to this problem. What worked best for me was always choosing a very trimmed-down container base image with only the bare minimum things to work.

One such container image is the distroless.

“Distroless” images contain only your application and its runtime dependencies. They do not have package managers, shells, or other programs you would expect to find in a standard Linux distribution.

More information about distroless can be found here.

In this blog, let me show you how easy it is to use a distroless image in a Spring Boot application.

Add the image to the project by using the jib-maven-plugin.

To add this plugin add the following in your pom.xml.

After adding the plugin, run the following command.

mvn clean install jib:dockerBuild

The above command will compile your code, create an image out of it, and then push it to the docker daemon.

Since we are using a jib, which is java focused, the base image by default comes from gcr.io/distroless/java8

In higher environments, however, you may want to add some configurations for the base image to build your application on top.

Two other benefits of using distroless and jib, in my opinion, are:-

1. Distroless images are tiny. The smallest distroless image gcr.io/distroless/static-debian11is around 2 MiB. That's about 50% of the size of alpine (~5 MiB) and less than 2% of the size of Debian (124 MiB).
2. Jib does an optimized build where it splits up the application into different layers—one for dependencies, one for resources, and one just for your classes. Thus if your application size was 50MB, your class layer might be 1MB. If anything changes in the code, the jib will compile the code and send the layer that has changed. The class layer being small in size, the docker push of the images is faster.

Disclaimer: The blog is based purely on my experience. There might be other good container images too. I would suggest the readers do their experiments and choose one.

Bye for now!