[nrvn]

you are not alone... https://socket.dev/blog/curl-project-and-go-security-teams-r...

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.

[junon]

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.

[fc417fc802]

> 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.

[ozim]

„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.