When creating Docker images, developers may start with base images that include unnecessary software components or libraries. This practice can lead to bloated images, increasing their size and resource consumption. For instance, using a base image like Ubuntu or CentOS, which come with a plethora of pre-installed packages, even if they are not required for the specific application, results in heavy Docker images. These images take longer to build, consume more storage space, and slow down deployment processes.
Developers should instead opt for lightweight base images tailored to the specific needs of their applications. For example, instead of using a full-fledged Linux distribution as the base image, choosing a slim or alpine variant significantly reduces image size and resource overhead. By using minimalistic base images, developers optimize resource utilization, improve build and start times, conserve storage space...
Non-compliant:
FROM python:3.8
# Image size: 356MB
Compliant:
FROM python:3.8-alpine
# Image size: 17MB
Non-compliant:
FROM debian:12.5
…
# Only the last FROM command impacts the final image size
FROM node:18:
# Image size: 352MB
Compliant:
FROM debian:12.5
…
# Only the last FROM command impacts the final image size
FROM node:18-slim:
# Image size: 65MB
Non-compliant:
FROM azul/zulu-openjdk:21
# Image size: 190MB
Compliant:
FROM azul/zulu-openjdk-distroless:21
# Image size: 153MB
Rule short description
Avoid using heavy Docker base images. Use minimal, application-specific base images, like alpine, or specialized, resource-optimized versions (e.g. python:3.8-alpine instead of python:3.8).
Rule justification
Why it matters:
For the image itself:
Image Size Reduction : Larger images require more storage, more time to transfer, and more resources to load into memory and execute.
For the containers created from the image:
Startup time: The more layers an image has, the longer it will take for the container to start up because each layer must be pulled from the registry and loaded into memory. This can be noticeable if you have many small layers, as the overhead of loading each layer can add up.
Disk usage: Each layer in an image adds to the size of the final image, which in turn affects the disk usage of the container. This can become a problem if you have many images or if you're working with limited disk space.
Security: Each layer in an image represents a potential attack surface, so minimizing the number of layers can improve the security of your container. This is because each layer can potentially contain vulnerabilities or malicious code that could be exploited
Do these versions frequently exist ?:
Yes, around 40% of the 1000 most popular images on dockerhub has a slim or alpine version (verified with a python script using the Dockerhub API on the first 1000 most popular images)
Severity: Major (Huge differences in the size of the images, e.g. 100Mo instead of 1Go, see impacts in previous section)
Cost: Easy (only the image version to change, so no need to understand the logic but potential impacts)
Implementation principle
To detect the non use of a lightweight docker image, we will have to find the last use of the FROM command in the Dockerfile (the ones before does not impact the final size of the image).
If the image used contains alpine or slim in the tag (version), or contains distroless in the repository (image name), we can consider the image lightweight, otherwise we can consider the rule broken.
Possible false positive: corporate custom images that do not follow naming conventions (alpine, slim, distroless).
Rule title
Use lightweight base image
Language and platform
Docker
Rule description
When creating Docker images, developers may start with base images that include unnecessary software components or libraries. This practice can lead to bloated images, increasing their size and resource consumption. For instance, using a base image like Ubuntu or CentOS, which come with a plethora of pre-installed packages, even if they are not required for the specific application, results in heavy Docker images. These images take longer to build, consume more storage space, and slow down deployment processes. Developers should instead opt for lightweight base images tailored to the specific needs of their applications. For example, instead of using a full-fledged Linux distribution as the base image, choosing a slim or alpine variant significantly reduces image size and resource overhead. By using minimalistic base images, developers optimize resource utilization, improve build and start times, conserve storage space...
Non-compliant:
Compliant:
Non-compliant:
Compliant:
Non-compliant:
Compliant:
Rule short description
Avoid using heavy Docker base images. Use minimal, application-specific base images, like alpine, or specialized, resource-optimized versions (e.g. python:3.8-alpine instead of python:3.8).
Rule justification
Why it matters:
Do these versions frequently exist ?:
Official documentation : https://docs.docker.com/develop/develop-images/guidelines/
Expert article : https://www.fullstack.com/labs/resources/blog/small-is-beautiful-how-container-size-impacts-deployment-and-resource-usage Measurement (from scientific article https://assets-eu.researchsquare.com/files/rs-3276965/v1_covered_8dc408b5-6997-486a-89c8-a5c66fddf60e.pdf?c=1693976849) :
Severity / Remediation Cost
Severity: Major (Huge differences in the size of the images, e.g. 100Mo instead of 1Go, see impacts in previous section)
Cost: Easy (only the image version to change, so no need to understand the logic but potential impacts)
Implementation principle
To detect the non use of a lightweight docker image, we will have to find the last use of the
FROMcommand in the Dockerfile (the ones before does not impact the final size of the image). If the image used containsalpineorslimin the tag (version), or containsdistrolessin the repository (image name), we can consider the image lightweight, otherwise we can consider the rule broken.Possible false positive: corporate custom images that do not follow naming conventions (alpine, slim, distroless).