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.

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.