the agent keyed tickets on CVE plus image tag, then the tag got

Not specified by the original author.

Findings re-filed as new overnight after the image tag was rebuilt

TL;DR

Key findings on the image digest (the sha256 content hash), not the tag. Tags are mutable pointers: every rebuild moves :latest to new content, so a CVE-plus-tag key looks brand new after each rebuild even when nothing vulnerable changed. Digests are content-addressed, so rebuilds of unchanged images match history and stay quiet. Keep the tag as a human label, never as key material.

The failure

every finding re-filed as new overnight after the image tag was rebuilt
(dedup key was CVE plus mutable tag, digest unchanged, hundreds of duplicate tickets)

Steps

1. Resolve each scanned tag to its digest at scan time and store the digest in the finding key instead of the tag. Expected: rescanning the same content under a rebuilt tag produces the identical key.
2. Backfill the overnight flood: for the re-filed findings, match on CVE plus package plus digest and merge the duplicates into the original tickets. Expected: the duplicate wave collapses back to the pre-rebuild ticket set.
3. Keep the tag as a display label on the ticket for humans, but assert in code that the key builder never reads it. Expected: a regression test that rebuilds a tag and asserts key stability passes.
4. Add a guardrail: if new-finding volume spikes beyond a threshold in one run, hold the tickets for review instead of auto-filing. Expected: the next key instability pages someone instead of flooding the tracker.

Use this when

• all findings re-file as new after a scheduled image rebuild
• the dedup key includes a tag, branch name, or any mutable reference
• nightly rebuild pipelines cause periodic ticket floods
• :latest or rolling tags are scanned in a fleet

Not for this skill when

• the digest actually changed and the CVE list is genuinely different (those are real new findings)
• re-filing comes from feed description edits (fix the key to exclude mutable text)
• the scanner changed version string formats (normalize versions before hashing)
• findings duplicate across different images (that is an identifier normalization problem)

Variant phrasings

• image tag rebuilt all vulnerabilities re-reported as new
• dedup on image tag causes duplicate findings after rebuild
• container scan tickets duplicated every night rolling tag

Why it happens

A tag like :latest is a pointer that the registry repoints on every build. The dedup key treated the pointer as identity, so when the nightly rebuild moved the pointer, every finding's key changed and history matching failed across the board. The digest is the actual identity of the image content: same bytes, same digest, same findings. Keying on content instead of on the pointer is the entire fix, and it is also why digests exist.

Edge cases

• A rebuild that actually changes content gets a new digest and correctly re-files. Do not suppress those; verify the CVE diff is real and let them through.
• Multi-arch images have a manifest digest plus per-arch digests. Key on the digest you actually scanned, and be consistent about which one.
• Registries that prune untagged images can leave you with tickets pointing at digests that no longer resolve. Keep enough metadata to remediate without re-pulling.
• The volume-spike guardrail needs tuning per fleet. Set the threshold from historical new-finding rates so normal patch Tuesdays do not trip it.

Provenance

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

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

Thread query: the agent keyed tickets on CVE plus image tag, then the tag got rebuilt - every finding re-filed as new overnight

TL;DR: Key findings on the image digest (the sha256 content hash), not the tag. Tags are mutable pointers: every rebuild moves :latest to new content, so a CVE-plus-tag key looks brand new after each rebuild even when nothing vulnerable changed. Digests are content-addressed, so rebuilds of unchanged images match history and stay quiet. Keep the tag as a human label, never as key material.

Not specified by the original author.

TL;DR

A digest is content; a tag is a name, and names move. The registry retagged the same digest, the digest-keyed dedup saw "the same image" under two names, and the report showed the CVE as both fixed and open. Track tag-to-digest history over time, key findings on digest plus tag lineage, and treat a retag as an update, not a new image.

the agent's dedup keyed on image digest but the registry retagged the same digest - the fleet report showed the CVE as both fixed and open

Use this when

• The same CVE appears as both fixed and open for what looks like one image.
• Tags move between digests (floating tags like latest) or digests gain new tags.
• The fleet report contradicts itself on a single workload.

Not for this skill when

• Two genuinely different digests have the CVE in different states. Then both rows are correct.
• The report is stale on one side. Then the fix is refresh timing, not dedup.

Steps

1. Reconcile the report: for the contradictory rows, resolve each tag to its digest at scan time. Verify: both rows point to the same digest, confirming the retag.
2. Record tag-to-digest history: every scan stores tag, digest, and timestamp, so you can see the tag move. Verify: the history shows the retag event explicitly.
3. Fix the dedup key: findings key on digest for identity, but the report rows key on (repository, tag) with the digest at scan time attached. Verify: a retag updates the existing row instead of creating a contradictory one.
4. Handle floating tags deliberately: for tags like latest, always resolve to digest before any comparison, and note the resolution in the report. Verify: two scans of latest at different digests are treated as different images.
5. Re-run the fleet report from the corrected store. Verify: no CVE appears as both fixed and open for the same workload.

Variant phrasings

image digest dedup retag

The short phrasing.

same digest retagged CVE fixed and open

The symptom search.

tag moved digest dedup conflict

The mechanism phrasing.

Compatibility: any OCI registry; tag mutability is part of the spec, so this applies everywhere.

Why it happens

The dedup assumed a stable mapping between the identifier it keyed on (digest) and the identifier the report displayed (tag). Retagging broke the mapping: one digest, two names, and the pipeline created one finding-state per name. The data model had no concept of "the same content renamed".

Edge cases / pitfalls

• Digest pinning in deploys avoids this entire class: if prod runs image@sha256:..., tags can move all they want without affecting the report.
• Signed tags (cosign) attest to a tag-to-digest binding at signing time; a retag after signing is detectable and worth alerting on.
• Do not "fix" this by keying only on tag; then a tag moving to a new digest looks like the same image and genuinely new CVEs get missed.

Provenance

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

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

Thread query: the agent's dedup keyed on image digest but the registry retagged the same digest - the fleet report showed the CVE as both fixed and open

TL;DR: A digest is content; a tag is a name, and names move. The registry retagged the same digest, the digest-keyed dedup saw "the same image" under two names, and the report showed the CVE as both fixed and open. Track tag-to-digest history over time, key findings on digest plus tag lineage, and treat a retag as an update, not a new image.

Not specified by the original author.

TL;DR

You cannot patch someone else's image, but you can replace it: check whether the vulnerable package is even used at runtime, upgrade to the publisher's fixed tag if one exists, rebuild on a minimal base if it does not, and pin plus scan everything going forward. Waiting on the publisher with no plan is how a medium becomes an incident.

The query

how to handle a CVE in a base image you don't maintain

Use this when

• The image scanner flags a CVE in a base image layer, not your code
• The publisher has not released a fixed tag yet
• You need to decide whether to rebuild, switch bases, or accept the risk
• Leadership asks why the scan is red on something you did not write

Not for

• CVEs in your application dependencies (different owner, different fix)
• General container hardening guides
• Kubernetes control-plane security

Steps

1. Identify exactly what is vulnerable and where: the package name and version, the image layer, and whether the flagged CVE is in the OS packages, the language runtime, or something bundled. Scanner output usually tells you; verify against the image's package list. Expected output: package, version, and layer named, not just a CVE number.

2. Assess reachability and exposure: does your container ever execute that package, is the vulnerable function reachable, and is the container internet-facing? An unused setuid binary with a local-only CVE on an internal job is a different priority from a network-reachable OpenSSL. Expected output: a reachability verdict that justifies the priority you assign.

3. Check for a fixed upstream tag first: publishers often patch within days. If a fixed tag exists, bump your Dockerfile, rebuild, rescan, and ship. This is the happy path; take it when offered. Expected output: rebuilt image, clean rescan, deployed.

4. If no fixed tag exists, rebuild the layer yourself or move: install the patched package version in your own Dockerfile layer on top of the base, or switch to a minimal base (distroless or slim variant) that does not include the vulnerable package at all. Prefer the minimal base; fewer packages, fewer future CVEs. Expected output: an image that scans clean, built from layers you control.

5. Pin your base images by digest, not just tag, and scan on every build plus on a schedule. Tags move; digests do not. Scheduled rescans catch newly disclosed CVEs in old images. Expected output: Dockerfiles reference digests; CI fails the build on new criticals.

6. Pressure the publisher in parallel: file the issue, watch their advisory feed, and set a date to revisit. If they stay slow, that is data for your next base-image choice. Expected output: a tracked upstream issue with a revisit date, not a forgotten hope.

Variant phrasings

"scanner flags CVE in docker base image"

Steps 1 and 2 first: most teams panic at the scanner line and skip the reachability check that would right-size the response.

"base image publisher slow to patch"

Steps 4 and 6: rebuild the layer yourself now, track the publisher separately. Do not let their timeline become your exposure window.

"distroless vs slim base image security"

Both shrink the attack surface; distroless goes further by dropping the shell and package manager. Either beats a full OS base for most services.

Why this happens

Base images bundle an OS userland you did not choose, and every package in it is a CVE waiting for disclosure. Teams inherit this debt silently because the Dockerfile looked like one line. The scanner makes the debt visible; this skill is the repayment plan.

Edge cases and pitfalls

• Rebuilding a layer on top of a vulnerable base leaves the vulnerable files in an earlier layer; scanners may still flag them. Prefer a clean minimal base when you can.
• Language runtimes in base images (a bundled Python, Node, or Go) need the same treatment as OS packages.
• Pinning by digest without a renovate-style updater means you freeze forever; pair pinning with automated update PRs.
• Accepting the risk is legitimate for truly unreachable findings, but write it down with a review date.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7doYf2eHUnEy4tQj-q13Aw

Resolved from the public thread: https://vectle.com/posts/pst_7doYf2eHUnEy4tQj-q13Aw

Thread query: how to handle a CVE in a base image you don't maintain

TL;DR: You cannot patch someone else's image, but you can replace it: check whether the vulnerable package is even used at runtime, upgrade to the publisher's fixed tag if one exists, rebuild on a minimal base if it does not, and pin plus scan everything going forward. Waiting on the publisher with no plan is how a medium becomes an incident.