This is a great writeup, thanks! The only thing I think could be improved is the clarification between NVD and CVE -- the way you compare NVD to other databases could make the less informed think this is an argument to do away with CVE as a naming scheme (since GHSA, GSD, OSV use but don't require CVE). NVD as a database was always somewhat meh (in my opinion) and had limited utility. OSV and others are probably better and faster. But using CVE as a way to name/recognize vulnerabilities has been immensely helpful for the last 20+ years and this feels a little like throwing out the baby with the bathwater. What would be better (since CVE and NVD are distinct and separate) is to continue adovcating for the use of CVE across the board and other databases like OSV, GSD, etc. can enrich that data in whatever way makes sense to them -- but we still have a common naming scheme that allows us to reconcile vulnerabilities irrespective of source data. What's described here reminds me uncomfortable of the pre-CVE days where you had differing sources of data and were looking for a BID (Bugtraq id) which depended on whether SecurityFocus got around to making one. CVE solved a lot of those problems -- note _CVE_ solved them, not _NVD_. It's really worth pointing out that they are not one and the same.
Great post, Chris! Thanks for mentioning the paper that the OWASP SBOM Forum put out in 2022 on how the naming problem could be fixed in the NVD. That remains our recommendation, but to be quite honest, I've personally given up on the NVD ever fixing these problems. It's not that they don't care about them, but they're underfunded, and frankly, how can anyone work for an organization that is always on the chopping block in Congress?
I'm now advocating for a Global Vulnerability Database https://tomalrichblog.blogspot.com/2023/11/the-global-vulnerability-database-wont.html. It won't be a single database, but more of a "switching hub" for queries, to existing databases like NVD, OSV, OSS Index, GitHub advisories, etc. I never thought there would be a "naming emergency", but there seems to be one now. Anybody wishing to get involved with this effort should email me at tom@tomalrich.com
This is a great writeup, thanks! The only thing I think could be improved is the clarification between NVD and CVE -- the way you compare NVD to other databases could make the less informed think this is an argument to do away with CVE as a naming scheme (since GHSA, GSD, OSV use but don't require CVE). NVD as a database was always somewhat meh (in my opinion) and had limited utility. OSV and others are probably better and faster. But using CVE as a way to name/recognize vulnerabilities has been immensely helpful for the last 20+ years and this feels a little like throwing out the baby with the bathwater. What would be better (since CVE and NVD are distinct and separate) is to continue adovcating for the use of CVE across the board and other databases like OSV, GSD, etc. can enrich that data in whatever way makes sense to them -- but we still have a common naming scheme that allows us to reconcile vulnerabilities irrespective of source data. What's described here reminds me uncomfortable of the pre-CVE days where you had differing sources of data and were looking for a BID (Bugtraq id) which depended on whether SecurityFocus got around to making one. CVE solved a lot of those problems -- note _CVE_ solved them, not _NVD_. It's really worth pointing out that they are not one and the same.
Great post, Chris! Thanks for mentioning the paper that the OWASP SBOM Forum put out in 2022 on how the naming problem could be fixed in the NVD. That remains our recommendation, but to be quite honest, I've personally given up on the NVD ever fixing these problems. It's not that they don't care about them, but they're underfunded, and frankly, how can anyone work for an organization that is always on the chopping block in Congress?
I'm now advocating for a Global Vulnerability Database https://tomalrichblog.blogspot.com/2023/11/the-global-vulnerability-database-wont.html. It won't be a single database, but more of a "switching hub" for queries, to existing databases like NVD, OSV, OSS Index, GitHub advisories, etc. I never thought there would be a "naming emergency", but there seems to be one now. Anybody wishing to get involved with this effort should email me at tom@tomalrich.com