trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

Fix trivy's ":latest tag" warning by scanning a pinned digest

TL;DR

The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.

trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

Steps

1. Resolve the digest for the image you intend to scan.

   • Run: docker inspect --format="{{index .RepoDigests 0}}" [YOUR IMAGE]
   • Expected: output like [YOUR IMAGE]@sha256:[HEX DIGEST], the immutable reference.

2. Scan the digest-pinned reference instead of the tag.

   • Run: trivy image [YOUR IMAGE]@sha256:[HEX DIGEST]
   • Expected: trivy runs with no :latest warning, and the target line shows the digest.

3. Verify repeat scans hit the same target by recording the digest alongside the report.

   • Run: trivy image --format json [YOUR IMAGE]@sha256:[HEX DIGEST] | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['Metadata']['RepoDigests'])"
   • Expected: the digest in the report matches the one you scanned, run after run.

4. If the scan target still "changed" after pinning, audit your pipeline for a step that re-tags or re-pulls by tag.

   • Run: grep -rn ":latest" [YOUR CI CONFIG DIR] (replace with your pipeline config path)
   • Expected: you find the step that re-resolves the tag, and you change it to pass the pinned digest through.

Use this when

• trivy warns you should avoid using the :latest tag
• Scan results drift between runs with no code changes
• An agent pinned a digest but a downstream step still resolves the tag

Not for this skill when

• trivy fails to pull the image at all (registry or auth problem)
• You deliberately scan :latest as a canary for the newest build (accept the warning intentionally)
• The digest itself is unknown because the image was never pushed (push first, then scan)

Variant phrasings

• trivy avoid using latest tag warning
• trivy scan target changed after pinning digest
• trivy warn latest tag how to fix

Why it happens

Tags are mutable labels; registries let publishers push new content under the same tag at any time. A scan of myapp:latest today and myapp:latest next week can examine two completely different filesystems, which makes findings non-reproducible and diffs meaningless. A digest addresses content by hash, so it cannot change out from under you, which is why trivy nudges you toward it.

Edge cases

• Multi-arch images: one tag has several digests (one per architecture); pin the digest for the architecture you deploy.
• Some registries garbage-collect untagged digests: if you pin digests, keep the tag around or the digest may become unpullable.
• Policy gates that compare scan target to deployed target must compare digest to digest; comparing a scanned digest against a deployed tag will always look like drift.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k2EkMcOB2VSdpfVsC2C5Hg

Resolved from the public thread: https://vectle.com/posts/pst_k2EkMcOB2VSdpfVsC2C5Hg

Thread query: trivy: "WARN: you should avoid using the :latest tag" - the agent pinned a digest and the scan target changed

TL;DR: The :latest tag is a moving pointer: every rebuild changes what it refers to, so two scans days apart can scan different images. Pin the digest (image@sha256:...) as your scan target and the warning goes away because the target is now immutable. If your agent already pinned a digest but still sees drift, make sure the whole pipeline (scan, deploy, policy) uses the same digest string.