The prefix before the first hyphen names the database that issued the record. In the OSV format, GHSA is GitHub's advisory database, CVE comes from the National Vulnerability Database feed, DSA and DLA are Debian security advisories, and DEBIAN is the Debian Security Tracker. Knowing the source tells you what the record can and cannot say.
The pattern
An OSV identifier has the form database name, hyphen, entry ID. The schema gives examples: OSV-2020-111, CVE-2021-3114 and GHSA-vp9c-fpxx-744v. IDs may contain letters, digits, colons, hyphens, underscores and periods.
| Prefix | Home database, per the OSV schema |
|---|---|
| GHSA | GitHub Security Advisory Database |
| CVE | National Vulnerability Database (as provided by OSV.dev) |
| DSA, DLA, DTSA | Debian Security Advisory Database |
| DEBIAN | Debian Security Tracker |
Other databases can derive IDs from CVE records by adding their own prefix, as in DEBIAN-CVE-2000-0001. That tells you the Debian record was built from a CVE and is Debian's own statement about it.
Why the prefix matters when reading a finding
Each source has its own purpose and coverage.
- A GHSA record is GitHub's identifier. Reviewed advisories in that database have ecosystem and package information, and they can trigger Dependabot alerts. Unreviewed advisories are published automatically from the NVD feed, and Dependabot does not alert on them.
- A CVE record names the flaw in a general way. It is not tied to one distribution's packaging.
- A DSA or DLA record belongs to a distribution release. It states which package versions in that release carry the fix.
- A DEBIAN record from the tracker records the status of a flaw per package and release.
If a scan shows a CVE ID and a DSA ID for the same finding, they refer to the same underlying flaw, seen from two places. The distribution record is usually the better guide for a package installed from that distribution.
Reading the ID to decide where to look next
- Take the ID from the finding.
- Read the prefix and open the record at that database.
- Check the ecosystem and package fields. They tell you which package source the record covers.
- Look for aliases. OSV aliases list IDs for the same vulnerability in other databases. Two records are aliases if they affect a component in the same way.
- If the package comes from an operating system, prefer the distribution's record for the fixed version.
Aliases, upstream and related are different links
The OSV schema defines three relations.
| Field | Meaning |
|---|---|
| aliases | IDs for the same vulnerability in other databases. Symmetric and transitive |
| upstream | IDs of upstream vulnerabilities a downstream record refers to, such as a distribution advisory bundling several CVEs |
| related | Closely related vulnerabilities that do not meet the alias or upstream definitions |
So a DSA that bundles three CVEs lists them as upstream, not as aliases. If you merge findings by treating every link as an alias, you will collapse separate flaws into one.
A habit for ticket titles
Put the ID you were given in the ticket, and add the aliases you found. The next person who searches the tracker by CVE number will still find it.
Where the record is edited
IDs stay stable, but content changes. The schema's modified timestamp shows when a record was last changed, and later modification time wins if two entries claim the same ID. When a finding looks different from last week, compare the modified time.
Safeguard's SBOM and dependency scanning keep the advisory ID and its aliases attached to each finding, so you can trace a result to its source database. A free scan is at gold.safeguard.sh/scan.
Quick check
Does GHSA mean the flaw is only in GitHub's ecosystem?
No. GHSA is the identifier GitHub's database assigns. The same flaw may also have a CVE ID and distribution IDs.
Are upstream and alias the same thing in OSV?
No. Aliases name the same vulnerability in other databases. Upstream points to upstream vulnerabilities that a downstream record refers to, and it is not symmetric.
Sources
- OpenSSF, OSV schema
- GitHub Docs, About the GitHub Advisory database
Last reviewed: 19 October 2026.
