Why we ban the latest tag

The latest tag is the most dangerous default in container tooling. It means "whatever was pushed most recently," which means your pipeline ran a different image today than it did yesterday, and you have no way of knowing unless you checked the digest. Most teams do not check the digest.

The reproducibility problem

A pipeline should produce the same result given the same input. If your pipeline step uses node:22, that tag can point to a different image digest every week. Node publishes patch releases, the tag moves, and suddenly your build breaks — not because your code changed, but because the runtime changed under you.

Debugging this is miserable. The build passed yesterday. Nothing in the repo changed. The build fails today. You spend an hour before someone realizes that node:22 now points to 22.14.0 instead of 22.13.1, and the new version changed the behavior of a flag your build script depends on.

gittan's tag format

gittan enforces a tag format for all images used in pipelines: YYYYMMDD-HHMMSS-sha. For example: 20260615-143022-a1b2c3d.

The tag tells you exactly when the image was built and from which commit. It is immutable — the same tag always points to the same image. If you need to update, you build a new image and get a new tag. There is no ambiguity about what ran.

This is enforced at the org policy level. If a pipeline config references latest, stable, or any mutable tag, the push is rejected with a clear error explaining why and what format to use instead.

Updating images

The common objection is that pinned tags create upgrade friction. If every image has an explicit tag, someone has to bump it. That is true — and that is the point. An image update should be a deliberate decision, not something that happens silently in the background.

When you bump an image tag, the change shows up in the pipeline config diff. It is reviewable. It is revertible. If the new image breaks something, you can see exactly when the image changed and roll back to the previous tag. Try doing that with latest.

gittan's team reports include advisories when pipeline images have known vulnerabilities or are significantly outdated. The team sees "your build image is 90 days old and has 3 known CVEs" and can decide when to update. The update is on their terms, not forced by a tag that moved overnight.

Supply chain integrity

Immutable tags are the foundation of supply chain integrity. If you sign an image at tag 20260615-143022-a1b2c3d, you know exactly what you signed. If you sign latest, you signed whatever happened to be there at that moment — and it will be something different tomorrow.

This principle extends beyond images. In a gittan pipeline, everything has a pin — modules are content-addressed by digest, not floating tag. The same rule, applied consistently: if it can change under you without your knowledge, it is not pinned, and it does not belong in your pipeline.

Combined with org policies that enforce image registry sources and image signing, the tag format creates a verifiable chain from source commit to running container. Every step in the pipeline used a known image, built from a known commit, signed by a known key. That is auditable. That is reproducible. And it starts with not using latest.