Recurring incidents like these raise the question, how does one strike a balance?
Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.
On the flip side, would it be ethical if security practitioners, including novices, sat on what they thought was a security flaw—so as not to inconvenience the project maintainers?
This was already answered in the article: verify your security findings. Make a POC that actually exploits the vulnerability, then submit it with your report.
I think a good alternative is a CVE is assigned as somewhere between 1-3 unless proof of concept is able to be assigned, then and only then can the priority to increased to what it should be. these issue reports coming in as a 9 when you basically need to tell the program, “hey I’m being stupid just do it” in order for it to be vulnerable are only wasting developers time. I don’t believe these issues should be ignored however I do think they should be quite a bit lower priority if no concept is provided.
This was already answered in the article: verify your security findings. Make a POC that actually exploits the vulnerability, then submit it with your report.
I think a good alternative is a CVE is assigned as somewhere between 1-3 unless proof of concept is able to be assigned, then and only then can the priority to increased to what it should be. these issue reports coming in as a 9 when you basically need to tell the program, “hey I’m being stupid just do it” in order for it to be vulnerable are only wasting developers time. I don’t believe these issues should be ignored however I do think they should be quite a bit lower priority if no concept is provided.