CVE identifies a vulnerability. GHSA identifies an advisory in the GitHub Advisory Database. USN is an Ubuntu Security Notice and DSA is a Debian Security Advisory, each naming the fix for that distribution. One vulnerability can carry several IDs, so track the CVE and keep the others as links.
The IDs, side by side
| ID | Who issues it | What it identifies |
|---|---|---|
| CVE | A CVE Numbering Authority | A publicly known vulnerability |
| GHSA | GitHub | An advisory in the GitHub Advisory Database |
| USN | Ubuntu Security team | A notice that a security issue was fixed in an official Ubuntu package |
| DSA | Debian security team | An advisory for a fix in Debian, with the fixed package versions |
CISA describes a CVE ID as a unique, common identifier for a publicly known cybersecurity vulnerability. GitHub says each security advisory has a unique GHSA ID. Ubuntu issues a USN when a security issue is fixed in an official package, and Debian publishes a DSA for issues it considers serious.
The OSV feed adds more prefixes. Reading its recent changes, you will see IDs that are not CVEs at all, such as ones for Python or for malicious packages. Treat the ID as a label in a source, and use the aliases field to find related IDs.
One flaw, several records
Take an open source library flaw. A CNA assigns a CVE. GitHub publishes a GHSA that lists affected package versions in a machine-readable form. Debian and Ubuntu each publish their own notice naming the package version that contains their backported fix.
These records are about the same underlying problem but answer different questions:
- The CVE says what the flaw is.
- The GHSA says which package versions in a registry are affected and fixed.
- The USN or DSA says which version to install on your distribution.
Pick the record that matches the thing you run. A container based on a Debian image takes its fix from the DSA, and an npm project takes it from the registry advisory.
Rules of thumb for your ticket system
- Use the CVE as the primary key when one exists.
- Store every other ID in a related-IDs field, so someone can paste any ID into a search and find the ticket.
- When there is no CVE, as with some ecosystem advisories, use the source ID and say so.
- Never close a ticket because one ID is fixed. Check the ID for each ecosystem you run.
- Record the fixed version in the vendor's own format, including suffixes.
Watch the revision suffixes
Notices carry revisions. In Ubuntu, a suffix such as dash 2 or dash 3 on the notice number indicates a further notice in the series, often for another variant or release. Debian does something similar: its recent list includes DSA-6567-1 for cifs-utils and a regression update numbered DSA-6567-2. Always read the newest notice in the series.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how each component can have several advisory references against it, and how they roll up to one finding.
Safeguard dependency scanning joins these records onto your SBOM so a team sees one finding. A free scan is a quick way to look.
Quick check
Is a GHSA the same as a CVE?
No. A GHSA is a GitHub advisory ID. It often links to a CVE but is its own record.
Which ID should my ticket use?
Use the CVE as the primary key where one exists, and store the other IDs as related references.
Sources
- CISA, Known Exploited Vulnerabilities
- GitHub Docs, About the GitHub Advisory database
- Ubuntu, Security notices
- Debian, Security information
- OSV, Data sources
Last reviewed: 19 October 2026.
