When a Dockerfile image is not tagged with a specific version, it is referred to as latest. This means that every time the image is built, deployed, or run, it will always use the latest version of the image.

Why is this an issue?

While using always the latest version may seem convenient, the build cannot be repeated because it is not clear which was the last version. In addition, it can lead to unpredictability and issues such as version mismatch and potential security vulnerabilities.

What is the potential impact?

For example, if a developer builds and deploys an application using my-image:latest, they may unknowingly be using a different version of the image than another developer who also built and deployed the same application using my-image:latest. This can lead to version mismatches, which can cause bugs or compatibility issues.

In addition, using latest as the tag for Dockerfile images can potentially introduce security vulnerabilities. For instance, if a security vulnerability is discovered in an image and a new version is released to fix it, using latest as the tag means that the application will automatically use the updated image, even if it has not been properly tested and vetted for compatibility with the application.

How to fix it

To avoid these issues, it is recommended to use specific version tags for Dockerfile images.

This can be done by appending the version number or tag to the Dockerfile image name. For example, instead of my-image:latest, it is better to use my-image:1.2.3-alpine or my-image:1.2.3.

For even more control and traceability, it is also possible to specify your image by digest using the sha256 of the image. This will pin your image to a specific version in time, but will also exclude it from eventual security updates. An example would be using my-image@sha256:26c68657ccce2cb0a31b330cb0be2b5e108d467f641c62e13ab40cbec258c68d.

More information can be found in the documentation at the end.

Code examples

Noncompliant code example

FROM my-image
FROM my-image:latest

Compliant solution

FROM my-image:1.2.3
FROM my-image:1.2.3-alpine

How does this work?

This way, the same version of the Dockerfile image is used every time the application is built, deployed, or run, ensuring consistency and predictability across different environments. It is also not enough to use the latest tag, as this version also changes with each release.

Going the extra mile

Adhering to this can also make it easier to track which version of the Dockerfile image is being used, which can be useful for debugging and troubleshooting purposes.