Dealing with junk CVEs

[pombredanne]

See https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/
We need to find a way to ensure we can filter and tag junk CVEs like this quickly, especially on popular packages like cURL where the junk will be a cause of major churn.

[Hritik14]

Related:

• https://nvd.nist.gov/vuln/detail/CVE-2020-19909
• https://www.cve.org/CVERecord?id=CVE-2020-19909
• https://web.archive.org/web/20230825235241/https://nvd.nist.gov/vuln/detail/CVE-2020-19909

[pombredanne]

We need to design a status with multiple values such as rejected or disputed or else.

[armijnhemel]

https://keepassxc.org/blog/2023-06-20-cve-202335866/

[armijnhemel]

https://lwn.net/Articles/944209/ <-- currently subscribers only, but will be public in a few weeks. Well worth the read.

[armijnhemel]

https://www.postgresql.org/about/news/cve-2020-21469-is-not-a-security-vulnerability-2701/

[DennisClark]

Consider. Security Status values include:

• Reported: Initial status of a new vulnerability.
• Published: The reported vulnerability is confirmed to be real.
• Disputed: There is no community consensus regarding the state of the vulnerability and there could be an ongoing discussion.
• Rejected: The reported vulnerability is not real.

Note that these proposed status values do not attempt to address the reconciliation of different Severity levels suggested/reported by various sources. If that is a requirement also, we may need to refine these status values further. But the primary goal is to identify real Vulnerabilities that I need to care about and investigate vs reported Vulnerabilities that are not substantiated.

[TG1999]

@DennisClark what should be the criteria for a vulnerability status to be published? As I understand once we import a VCID from an advisory source we add a status Reported when should it change to Published?

[DennisClark]

After further thought: instead of Published we should have this:

Confirmed : A vulnerability that was formerly Disputed has been confirmed to be a real problem.

If it's not possible to determine that kind of state change from the advisories, then I guess we really don't need Confirmed, and the other 3 should be sufficient.

[TG1999]

As discussed in today's VCIO call taking reference from https://nvd.nist.gov/vuln/vulnerability-status, we will use Reserved, Published, Disputed and Rejected

[TG1999]

We are considering PUBLISHED, DISPUTED, and INVALID statuses for vulnerabilities. These should also be tracked in History and logged.

[DennisClark]

Let's use use Published, Disputed and Invalid please.