Clarification on difference between CVE and DEBIAN-CVE records in OSV

[SURENKUMAR-0212]

Hi OSV team,

I noticed that OSV contains two types of CVE-related vulnerability records:

• CVE-*
• DEBIAN-CVE-*

Could you please clarify the difference between these?

My understanding:

• CVE-* represents the general vulnerability record.
• DEBIAN-CVE-* represents Debian-specific vulnerability data from the Debian Security Tracker, including Debian package affected versions and fixes.

Questions:

1. Should CVE-* and DEBIAN-CVE-* be considered the same vulnerability from different sources?
2. How should consumers handle duplicates when both are returned by OSV?
3. For Debian packages, should DEBIAN-CVE-* be preferred over the generic CVE-*?

Thanks!

[github-actions]

✨ Thank you for your interest in OSV.dev's data quality! ✨

Please review our FAQ entry on how to most efficiently have this addressed.

[jess-lowe]

Hi there,

CVE-* records generally represent upstream records (where we have been able to resolve Git commit ranges from CVEList or NVD), while DEBIAN-CVE-* records are ingested directly from the Debian Security Tracker and describe how the vulnerability specifically affects the Debian ecosystem.

To answer your questions directly:

1. Should CVE-* and DEBIAN-CVE-* be considered the same vulnerability from different sources?

Yes, they represent the same underlying vulnerability, but they are describing it in the context of different environments.

2. How should consumers handle duplicates when both are returned by OSV?

It comes down to how the software is installed in your environment. If you are running Debian and installed the software via the Debian package manager (apt/dpkg), you should listen to the DEBIAN-CVE-/DSA records. However, if you installed the software outside of the package manager (e.g., compiled from source, used pip/npm, or downloaded a standalone binary), the Debian-specific patches don't apply to that installation, and you should look at the generic CVE- record instead.

3. For Debian packages, should DEBIAN-CVE-* be preferred over the generic CVE-*?

Yes. If you are specifically dealing with Debian packages, the DEBIAN-CVE-* record or DSA records should be preferred as they will have the most accurate, Debian-specific data regarding affected versions, backports, and fixes, but again it depends on how it was installed.

Hope that helps :)

[SURENKUMAR-0212]

Thank you for the detailed clarification. Your explanation made things much clearer.

I have one last question regarding the Debian data.

While looking through all.zip, I noticed that the CVE records all appear to be withdrawn/rejected CVEs (they have a withdrawn date). I couldn't find any "normal" published CVE records—only DEBIAN-CVE records for regular vulnerabilities.

From what I observed, there are around 290 CVE records in all.zip, and all of them have a withdrawn date.

Could you please help me understand why all.zip includes only the withdrawn CVE records and not the regular published CVE records? I'm trying to understand the reasoning behind this behavior.

Current Understanding

Based on the current OSV design, my understanding is that OSV avoids duplicating active upstream CVE records in the Debian ecosystem by representing active Debian vulnerabilities through DEBIAN-CVE records instead. However, withdrawn CVE records are retained to preserve historical consistency and indicate that the original CVE identifier has been withdrawn.

[jess-lowe]

I assume the all.zip you referring to is the gs://osv-vulnerabilities/Debian/all.zip? The high level gs://osv-vulnerabilities/all.zip should have all 91k+ records we've ingested in it.

The 290 CVE records you're referring to are probably an artifact left over from a few months ago where we migrated Debian records from being part of the high level CVE-x record to its own prefix, and they weren't cleaned from the Debian bucket correctly. They were likely rejected upstream before our transition to the new prefix, so have the withdrawn label under the CVE- prefix, and were just never regenerated under the new prefix as they don't serve much of a purpose for matching.

[SURENKUMAR-0212]

Thank you so much for your help and the update. Really appreciate your time and support!