Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think a better approach would be to acknowledge that the CVE system thoroughly conflates two almost orthogonal things:

1. CVE numbers are a way to refer to a (potential) issue. With a CVE number, one can look up an issue in a distro bug tracker or ask support a question or search mailing lists.

2. A CVE number comes with an assessment of whether an issue is real and how bad it is, often in the NVD.

From the FAQ [0]:

> No, CVE is not a vulnerability database. CVE enables the correlation of vulnerability data across tools, databases, and people. This enables two or more people or tools to refer to a vulnerability and know they are referring to the same issue.

So I think that a CVE should probably be rejected if it’s a duplicate, but not just for being a non-issue. But anyone using a CVE as evidence that an issue exists and thinks that NVD is doing a bad job should complain about the NVD, not CVE spam. And people should be extremely cautious about expecting the number of CVEs to mean much.

[0] https://www.cve.org/ResourcesSupport/FAQs#pc_introcve_nvd_re...



> No, CVE is not a vulnerability database

"No, Common Vulnerabilities and Exposures is not a vulnerability database."

Yeah, IDK where anyone got that idea.


They're a conflation of multiple lifecycle states: reported, confirmed, disclosed, patch available, and exploit available.

Perhaps the simplest way to reduce noise is to have 2 numbering systems: provisional "prepress" PCVE and confirmed CVE.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: