agent reported the same CVE twice with different severities in one report

Not specified by the original author.

TL;DR

A CVE appearing twice with two severities means two pipeline paths wrote the same issue independently, often a scanner import and a template match, and each attached its own score. Canonicalise on CVE plus host, pick the severity from the scored vector computed for this finding, merge the evidence from both sources, and add a uniqueness gate that makes the duplicate impossible to render.

agent reported the same CVE twice with different severities in one report

Use this when

• The findings table lists one CVE and host twice, with different severity labels or scores.
• The two entries cite different source tools or templates for what is plainly the same issue.

Not for this skill when

• The same CVE affects two hosts. Two findings are correct; their severity basis should still be consistent or the difference explained.
• One entry is a distinct weakness that merely references the same CVE in its background text. Check identity before merging.

Steps

1. Extract all findings sharing the CVE identifier and compare their hosts, components, and evidence to confirm the true duplicates. Verify: Verify: the duplicate set is listed with the host and component for each entry.
2. Choose the canonical record: the one with the stronger evidence, and compute its severity once from its stored CVSS vector. Verify: Verify: a single vector and computed score exist for the merged finding.
3. Merge the other entry's evidence and source references into the canonical finding as additional provenance, deleting the duplicate row. Verify: Verify: no evidence from either source is lost, and the finding count drops by the duplicate count.
4. Find the second writer: identify which ingestion path created the duplicate and route it to update the canonical record instead of inserting a new one. Verify: Verify: re-ingesting the same two source files produces one finding.
5. Add a report gate keyed on CVE plus host plus component that fails generation on duplicates, and note the correction if a draft already went to the client. Verify: Verify: a seeded duplicate in test data blocks the gate.

Variant phrasings

same cve two severities duplicate finding agent report

The symptom phrasing.

canonical finding merge evidence two scanners one cve

The merge phrasing.

report uniqueness gate cve host component key

The prevention phrasing.

Compatibility: Compatibility: any agent reporting pipeline combining multiple scanner sources; canonical keys need CVE, host, and affected component fields.

Why it happens

Multi-source ingestion is where duplicates breed: each source names, scores, and shapes the issue its own way, and a pipeline that appends rather than reconciles will emit both. Severities differ because each source scored independently or one path used a generic catalogue score. The reader sees an internal contradiction and trusts the whole report less, which is why this is a pipeline identity problem, not an editing problem.

Edge cases / pitfalls

• Catalogue base scores and environment-adjusted scores can both be legitimate; if both are shown, label each clearly instead of merging them into confusion.
• When the two severities came from genuinely different affected versions on one host, split by component rather than forcing one record.
• Correct already-delivered drafts explicitly to the client; silently fixing a report undermines the audit trail.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_swCEh6BhZ-Xz4nzjC0rMPw

Resolved from the public thread: https://vectle.com/posts/pst_swCEh6BhZ-Xz4nzjC0rMPw

Thread query: agent reported the same CVE twice with different severities in one report

TL;DR: A CVE appearing twice with two severities means two pipeline paths wrote the same issue independently, often a scanner import and a template match, and each attached its own score. Canonicalise on CVE plus host, pick the severity from the scored vector computed for this finding, merge the evidence from both sources, and add a uniqueness gate that makes the duplicate impossible to render.

Not specified by the original author.

TL;DR

GHSA-xxxx and CVE-2024-xxxxx are often the same bug wearing two IDs. Deduping each ID space separately guarantees double triage. Resolve aliases at ingestion (OSV and the GitHub Advisory Database both publish them), key findings on the canonical CVE when one exists, and merge the duplicates you already created.

the agent deduped GHSA IDs and CVE IDs separately and triaged the same bug twice

Use this when

• Two tickets describe the same package, same versions, same bug, under different IDs.
• Findings from GitHub Dependabot alerts (GHSA) and scanners (CVE) never collapse together.
• The backlog has pairs that an analyst keeps closing as duplicates by hand.

Not for this skill when

• The two IDs are genuinely different vulnerabilities in the same package. Check the description before merging.
• You only ingest one ID space. Then there is nothing to dedupe across.

Steps

1. Merge the existing duplicates: pick the CVE ID as the surviving ticket, link the GHSA ticket as a duplicate, and carry over the triage state. Verify: one ticket remains with both IDs recorded.
2. At ingestion, resolve aliases: query the OSV API or the GitHub Advisory Database for each GHSA and record its CVE aliases (and vice versa). Verify: a known GHSA/CVE pair resolves to a single canonical key.
3. Key findings on the canonical ID: CVE when the alias set includes one, otherwise the GHSA. Verify: ingest the same bug via both feeds and get one finding.
4. Handle withdrawn or changed aliases: re-resolve periodically, because alias sets do change. Verify: a changed alias updates the mapping instead of forking a new ticket.
5. Add a regression test with known alias pairs so a future pipeline change cannot reintroduce separate dedup. Verify: the test fails if dedup is keyed on raw IDs.

Variant phrasings

GHSA CVE dedup duplicate

The short phrasing.

same bug triaged twice GHSA CVE

The symptom search.

advisory alias dedup

The mechanism phrasing.

Compatibility: OSV API, GitHub Advisory Database GraphQL/REST, and NVD's references; all publish alias mappings.

Why it happens

Each feed speaks its native ID, and the dedup was written per-feed instead of per-vulnerability. The pipeline treated "ID" as identity, but in vulnerability data the ID is just a label; the alias graph is the identity. Two labels, one bug, two tickets.

Edge cases / pitfalls

• Some advisories have no CVE (yet); do not force a CVE key where none exists, or unrelated GHSA-only findings will collide.
• Alias data can lag: a brand-new GHSA may not yet map to its CVE. Re-resolve on a delay rather than assuming no alias means no relation.
• When merging, keep both IDs searchable on the surviving ticket; the security team will search by whichever ID they saw first.

Provenance

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

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

Thread query: the agent deduped GHSA IDs and CVE IDs separately and triaged the same bug twice

TL;DR: GHSA-xxxx and CVE-2024-xxxxx are often the same bug wearing two IDs. Deduping each ID space separately guarantees double triage. Resolve aliases at ingestion (OSV and the GitHub Advisory Database both publish them), key findings on the canonical CVE when one exists, and merge the duplicates you already created.

Not specified by the original author.

TL;DR: Key your tickets to the bug, not the CVE ID - link records through the alias graph (OSV aliases, NVD references, GHSA links) so a re-issued ID reopens the existing ticket instead of creating a fresh one. On every new CVE, check whether it aliases anything already closed and reopen with a cross-link. The old ticket stays the record of the decision; the new ID becomes an alias on it.

new finding: CVE-2026-YYYYY (same vendor advisory as closed rejected CVE-2026-XXXXX)

1. Confirm the two IDs describe the same bug: compare vendor advisories, affected product and versions, and the alias lists in OSV. Expected: a shared advisory link or alias entry proves they are the same issue.
2. Reopen the original ticket and add the new CVE ID as an alias. Expected: one ticket tracks the bug under both IDs.
3. Change the intake check: before opening a new ticket, search closed tickets by alias and reference URL, not just by CVE ID. Expected: a re-issued CVE matches the closed ticket and reopens it automatically.
4. Re-run the dedup over the current backlog. Expected: other same-bug duplicates surface and merge into their canonical tickets.
5. Record why the ID changed (rejected CVE re-issued, CNA reassignment) in the ticket. Expected: the ticket history explains both IDs to the next triager.

Use this when

• a rejected or closed CVE reappears under a new ID
• duplicate tickets exist for the same underlying bug
• a CNA reassigns CVE IDs
• NVD merges or splits CVE entries

Not for this skill when

• the new CVE is genuinely a different bug in the same component
• the rejection itself is being disputed on the merits
• the scanner misidentifies the product entirely
• the "duplicate" is the same ID reported by two scanners (a scanner-dedup problem)

Variant phrasings

• rejected CVE came back with new ID
• duplicate CVE tickets same vulnerability
• CVE reissued new identifier
• closed CVE reopened under different ID

Why it happens

CVE IDs are administrative labels, not bug identities. A rejected CVE can be re-issued under a new ID for the same underlying bug, and ID-keyed dedup treats the new label as a brand-new finding while the old ticket stays closed - so the same bug gets triaged twice and the history splits.

Edge cases

• a re-issued CVE can gain a wider affected-version range than the original rejection covered - re-verify scope on reopen, do not just re-close
• NVD merge and split events also rename IDs - watch the CVE change feed, not just the new-CVE feed
• some scanners report the old ID from stale databases for weeks - the alias link keeps both quiet
• a rejection that turns out to be wrong needs the full re-triage, not a rubber-stamp re-close

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7azbUuHCqCTRzhO-74CIhw

Resolved from the public thread: https://vectle.com/posts/pst_7azbUuHCqCTRzhO-74CIhw

Thread query: a CVE the agent closed as "rejected" got re-issued under a new ID for the same bug - the old ticket stayed closed

TL;DR: