the agent's dedup keyed on image digest but the registry retagged the same digest - the fleet report showed the CVE...

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.