Docker image owners can push new versions to the same tags, which may result in inconsistent images during builds, and makes it hard to track if a vulnerability has been fixed.
Prefer one of the following:
A verbose image tag with which to pin both version and operating system, for example:
FROM node:8-alpine
An image hash to pin the exact contact, for example:
FROM node:<hash>
Each Docker image can have multiple tags, which are variants of the same images.
The most common tag is latest, which represents the latest version of the image.
Image tags are not immutable, and the author of the images can publish the same tag multiple times.
This means that the base image for your Docker file might change between builds. This could result in inconsistent behavior because of changes made to the base image.
There are multiple ways to mitigate this issue:
Prefer the most specific tag available. If the image has multiple tags, such as :8 and :8.0.1 or even :8.0.1-alpine, prefer the latter, as it is the most specific image reference. Avoid using the most generic tags, such as latest. Keep in mind that when pinning a specific tag, it might be deleted eventually.
To mitigate the issue of a specific image tag becoming unavailable and becoming a show-stopper for teams that rely on it, consider running a local mirror of this image in a registry or account that is under your own control. It’s important to take into account the maintenance overhead required for this approach—because it means you need to maintain a registry. Replicating the image you want to use in a registry that you own is good practice to make sure that the image you use does not change.
Be very specific! Instead of pulling a tag, pull an image using the specific SHA256 reference of the Docker image, which guarantees you get the same image for every pull. However notice that using a SHA256 reference can be risky, if the image changes that hash might not exist anymore.