the vuln triage agent kept re-flagging the same CVE as new - the dedup key changed because the advisory feed updated...

Triage agent re-flags the same CVE as new after feed description updates

TL;DR

Rebuild the dedup key from immutable fields only: CVE ID plus package name plus installed version (or image digest for containers). Advisory descriptions get edited constantly for clarity, translations, and corrections, so any key containing them rots on the next feed update. After the fix, recompute keys for open tickets so history matches again and the duplicates collapse.

The failure

same CVE re-filed as a new finding after the advisory feed edited its description text
(dedup key included the description, hash changed, history match failed)

Steps

1. Redefine the dedup key as CVE ID plus package name plus installed version, and for container findings use the image digest instead of the tag. Expected: the key contains nothing any feed can edit.

1. Recompute keys for all open tickets and merge the duplicates that the broken key created. Expected: the duplicate backlog collapses to one ticket per real finding.

1. Add a regression test: take a fixture feed, change only the description text, and assert the dedup key is unchanged. Expected: the test fails if anyone ever puts mutable text back into the key.

1. Version the key format (e.g. prefix keys with v2) so future key changes migrate cleanly instead of orphaning history. Expected: old and new keys are distinguishable during migration.

Use this when

• the same CVE keeps getting re-filed as new with no change in your inventory
• finding counts spike after a feed update with no new vulnerabilities
• the dedup key includes description, summary, or any advisory prose
• ticket volume grows while the actual vulnerable surface stays flat

Not for this skill when

• re-filed findings come from rebuilt image tags (that is a mutable-tag problem, key on digests)
• the scanner changed its version string format (normalize versions before hashing)
• findings are genuinely new CVEs on the same package (correct behavior, not a dedup bug)
• the dedup store itself was wiped (restore the store, the key is fine)

Variant phrasings

• vulnerability dedup key unstable description text changed
• same CVE filed twice after advisory update
• triage agent re-opens closed CVEs as new findings

Why it happens

Dedup keys must be stable across feed updates, but advisory feeds are living documents: descriptions get rewritten, summaries get corrected, translations get added. A key that hashes any of that text changes every time the feed editors touch the prose, even though nothing about your exposure changed. The key then misses its own history, the finding looks new, and a fresh ticket opens. Immutable identity for a finding is the CVE ID plus what is installed where, full stop. Everything else is commentary.

Edge cases

• Rejected or merged CVEs change identity legitimately. Handle those with an alias map, not by making the key fuzzy.
• Two scanners may report the same CVE under different identifiers. Normalize to canonical CVE IDs before keying or the dedup misses across scanners.
• Version normalization matters: "1.2.3" versus "1.2.3-1" are different strings for the same exposure. Normalize before hashing.
• During the v1 to v2 key migration, run both keys in parallel for one cycle so in-flight findings do not get double-filed.

Provenance

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