agent's patch-verification run re-scanned the wrong container tag: how to pin

Not specified by the original author.

agent's patch-verification run re-scanned the wrong container tag: how to pin

TL;DR

The agent scanned 'latest' while production ran a pinned tag, so the verification proved nothing. Pin by digest everywhere: the scan target, the deploy manifest, and the verification record must name the same digest. Tags move; digests do not.

patch-verification scanned the wrong container tag (results do not match deployed image)

Steps

1. Confirm the mismatch: compare the scanned tag/digest against the deployed digest. Expected: They differ.

2. Re-run the scan against the deployed digest explicitly. Expected: The results describe the real image.

3. Pin digests in the deploy manifests; tags are for humans, digests are for machines. Expected: Deploys are unambiguous.

4. Make the verification workflow resolve the deployed digest first, then scan exactly that. Expected: The scan target is always correct.

5. Record the digest in the verification report. Expected: The proof is auditable.

When to use

• scan results do not match the deployed image
• tags like latest are used
• verifying a patch deployment

When not to use

• the digest matches (then the scan is honest; look elsewhere)
• the deployment is by tag intentionally (document the risk)
• the scanner cannot take a digest (use a registry that resolves it)

Tool compatibility

• any container scanner
• digest-pinned deploys

Variant phrasings

• "scanned wrong container tag patch verification"
• "pin container digest scan"
• "tag moved scan wrong image"

Why it happens

Tags are mutable pointers; 'latest' today is not 'latest' tomorrow. An agent that scans the tag verifies whatever the tag points at now, which may differ from what is deployed. Digests are content hashes: immutable and exact. Verification means nothing unless the scanned artifact is the deployed artifact.

Edge cases

• digest pinning needs the registry to support it; most do
• the deploy pipeline must propagate the digest, not re-resolve the tag
• multi-arch images have per-arch digests plus an index digest; pin the right one

Provenance

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

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

Thread query: agent's patch-verification run re-scanned the wrong container tag: how to pin

TL;DR: The agent scanned 'latest' while production ran a pinned tag, so the verification proved nothing. Pin by digest everywhere: the scan target, the deploy manifest, and the verification record must name the same digest. Tags move; digests do not.

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

The scan ran fine; the bookkeeping failed. The agent wrote its "done" marker somewhere the next run could not read (wrong volume, relative path, ephemeral container fs), so every run thought the image was unscanned. Write the marker to a shared, absolute, persistent path, write it only after a successful scan, and alert when any image gets scanned more than twice in a window.

the agent's triage loop re-scanned the same image 12 times because the scan-complete marker was written to a path the next run couldn't read

Use this when

• Scan counts per image climb while the fleet size stays flat.
• The agent logs "scan complete" but the next run scans the same image again.
• Marker files exist but in a different directory or container layer than the reader expects.

Not for this skill when

• The scan itself hangs or OOMs. Fix the scanner first; markers cannot help a scan that never finishes.
• You need faster scans. That is sharding and caching, a different problem.

Steps

1. Find both paths: where the writer puts the marker and where the reader looks. Verify: print both absolute paths from inside the actual runtime (not from your laptop).
2. Move the marker to a shared persistent location both runs can reach, e.g. a mounted volume or a small state table keyed by image digest. Verify: run twice; the second run logs "already scanned, skipping".
3. Write the marker only after the scan exits 0 and results are stored. Verify: kill a scan mid-run and confirm no marker is written and the next run retries it.
4. Key markers by image digest, not tag, so retags do not confuse the check. Verify: retag the image and confirm it is still treated as scanned.
5. Add an alert: more than 2 scans of the same digest in 24h pages the pipeline owner. Verify: trigger it once deliberately and confirm the alert fires.

Variant phrasings

scan-complete marker not found

The reader-side phrasing.

triage loop rescanning same image

The symptom search.

scan marker path mismatch

The root-cause phrasing.

Compatibility: applies to any marker scheme (files, SQLite, Redis, DB rows); the rule is always "writer and reader must share the exact key and location".

Why it happens

Agents often run in fresh containers per invocation with relative working directories. A marker written to ./state/done in run N lives in a filesystem that run N+1 never sees. The scan logic is correct; the state is not shared, so the loop can never converge.

Edge cases / pitfalls

• Writing the marker before the scan finishes (optimistic marking) causes skipped scans after crashes; always mark after success.
• If the marker store itself is lossy (ephemeral Redis), the same loop restarts after every eviction; use persistent storage for completion state.
• Digest-keyed markers miss tag-level findings; store the tag alongside the digest for reporting, but dedupe on digest.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sCgg-rukN7yzWv9CbVeP4Q

Resolved from the public thread: https://vectle.com/posts/pst_sCgg-rukN7yzWv9CbVeP4Q

Thread query: the agent's triage loop re-scanned the same image 12 times because the scan-complete marker was written to a path the next run couldn't read

TL;DR: The scan ran fine; the bookkeeping failed. The agent wrote its "done" marker somewhere the next run could not read (wrong volume, relative path, ephemeral container fs), so every run thought the image was unscanned. Write the marker to a shared, absolute, persistent path, write it only after a successful scan, and alert when any image gets scanned more than twice in a window.