Merge advisory aliases without merging different issues
Reconcile CVE, GHSA, and other advisory identifiers through explicit alias evidence. Preserve affected packages, source revisions, and separate upstream relationships.
Several feeds can describe the same vulnerability under different identifiers. Counting each identifier as a separate issue inflates the queue, but merging records by title can hide distinct defects. Use explicit relationship evidence and preserve the source records behind the combined view.
The OSV schema distinguishes aliases, upstream references, and related records. An alias identifies the same vulnerability. A related or upstream reference is not permission to collapse every affected package into one interchangeable record.
Keep source identity before deduplication
Store the original advisory identifier, source, revision time, affected packages, and relationship fields. Choose an internal tracking identifier for the combined issue rather than replacing the source identifiers.
| Relationship evidence | Suggested handling | Review concern |
|---|---|---|
| Explicit same-issue alias | Link under one internal issue | Retain all original records |
| Similar title only | Keep separate pending review | Similar symptoms can have different fixes |
| Upstream vulnerability reference | Link the dependency relationship | Distribution impact may differ |
| Related advisory | Show contextual link | Do not inherit affected ranges automatically |
| Conflicting relationship | Hold the merge for review | Preserve both sources and their dates |
Keep package occurrences below the issue level. One vulnerability can affect multiple installed versions or deployment artifacts that need separate remediation evidence.
Review the combined record
Compare the affected behavior, patch references, and package ecosystems. Check whether one advisory describes a distribution package that includes an upstream component, rather than the exact same advisory scope. Avoid carrying a fixed version from one ecosystem into another.
Retain source-specific severity and range data with attribution when feeds disagree. An internal normalized view can choose a reviewed display value, but it should not erase the disagreement or make that value appear universally authoritative.
Test updates and reversibility
Build small fixtures for two explicit aliases, two merely related records, and a corrected alias relationship. Verify that adding an alias does not duplicate remediation tasks and that removing an incorrect relationship restores the separate issue histories.
Preserve prior decisions and their evidence when feeds change. A ticket closed for one installed occurrence should not silently close another unresolved deployment after a merge. The finished reconciliation should let a reviewer answer which identifiers describe the issue, which components are affected, and why the records were linked. That is more useful than reducing the alert count without an auditable relationship model.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.