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 Docker 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 image name in the Dockerfile. For example, instead of using
my-image:latest, it is better to use
Noncompliant code example
How does this work?
This way, the same version of the 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 image is being used, which can be useful for debugging and troubleshooting