ReDos often get 7 or above since they can be "network accessible" (anything can be). CVSS is broken.
And yes, people who get scared file reports asking us to fix it, oftentimes we can't (because it's not a real vuln), and 99% of the time they're not even remotely affected. The requests are generally not very nice, either.
Most of the time, the request to fix a CVE is the first we've ever heard of it being filed. "Security research agencies" oftentimes have their own databases, and rarely do these "researchers" follow any amount of responsible disclosure, let alone even telling us about their findings or that they've filed. Many of them don't even cite a reporter, email, or any such contact information.
Especially when the CVE is nonsense, improperly scored, etc. there is almost no way to get it taken down or to reduce its severity. Apparently in the eyes of these agencies the people writing the code cannot adequately gauge the severity of vulnerabilities. It's nearing levels of almost zero collaboration with maintainers before things are filed.
I can't remember the last time I even had the opportunity to release a proper fix before a CVE went out. I can count on one hand the number of times I was asked before a CVE was filed. I don't think a single CVE of any code I maintain has had a score that properly reflected the severity of the actual vulnerability (assuming there even was one).
Remember, most of us do this in free time, for free. So all of the extra bureaucracy and synthesized urgency can be extremely detrimental.
I believe there must be some "Murphy's law" or something with a name for that situation. When there is an established system and process there will be people geniunely using and it will work 100% for such people and bring value to all parties. And then there will be people "gaming the system" (for instance "security" "researchers" using CVE created by them as a personal or corporate KPI) and abusing other legitimate players. It is like patent trolls but better fortunately for us.
Fortunately for all people of reason, the system itself gets patched. Maybe not in the best way possible but still. Two examples:
- Openvex - this is my way as a project owner/developer/maintainer to declare that CVE-XXXX-YYYYY is false positive and why.
- context-aware vulnerability scanning (or exploitability scanning) - govulncheck is a great example of that. You run and it says, module X has vulnerabilities Y and Z but you keep calm because we have not found any symbols in your codebase using it.
I wish more scanners would adopt the second approach and projects like npm would greatly benefit from it. As you truly note you pick a random project and it will be 50% filled with ReDos or something that will be sitting in some nested dependency of eslint's dep tree that will never see the light of production environment's CPU.
That being said, any vulnerability reporting and obtaining a CVE ID bypassing the project's security policies and responsible disclosure procedures must be prohibited. As a maintainer I want to know about a newly discovered vulnerability in my code to fix it and then the kind person that reported it to me can proceed to MITRE with the report in one hand and fixed version in the other.
Thanks for the link. I'm aware of curl's position on this but I haven't seen my own viewpoint so succinctly echoed in writing before; I'll definitely keep this on hand for future conversations!
Also interesting recommendations, I haven't heard of them either. One problem, having not tried any of these, is that if the "loud" mechanism (e.g. npm's audit tool) doesn't also check and reconcile, then it really doesn't do much good.
The people that open the issues and don't generally know what CVSS is, are not otherwise checking these databases first (oftentimes not even checking for duplicate issues, to begin with). Unless I can revoke a CVE or at least put in a correction, it will remain broken. Simple as that.
> The people that open the issues and don't generally know what CVSS is, are not otherwise checking these databases first
Add a notice to the issue template checklist to check the database. Maybe link to a wiki page that illustrates how. Mercilessly issue temporary bans for violations.
This is a spam issue plain and simple even if the perpetrator didn't intend it that way.
„Perverse incentive„ if you search wiki and „Cobra effect” as an example when British wanted to get rid of cobras Indians started breeding them as they would get paid for each dead Cobra.
