I am involved with an open source CMS project. Part of my role is triaging incoming emails to our project inbox. A gradually increasing percentage of these emails come from security researchers, advising us of issues they've found. We've had an uptick in overall volume this year after a crypto-funded bug bounty site appeared, found us, and a slew of reports landed. The majority of these reports weren't issues – rather, they can be summarised as "an administrator can do administrator-level stuff" within the CMS. We don't consider these vulnerabilities, and we say as much in our security statement.<p>More recently, we have had an increase in researchers with fuzzers, toolkits and other rapid-fire stuff. Around 90% of these researchers are focussed on getting a CVE. With the reports we receive, it's rare for a researcher to include a proof of concept, even after we politely request. It's typical for this type of researcher to say there's a problem with file X in directory Y, and btw please can I have a CVE now for my research project / wall / work promotion / and so on.<p>I'm not sure how this sits with me. Researchers who provide info, PoC code, and sometimes even a resolution are very straightforward to deal with – and hugely appreciated. My gut feeling with the fuzzer-type researcher is that they're taking the spray-and-pray approach as CVE or beg bounty hunters, and that's less clear cut from a comms point of view. I don't want to be getting into semantics with those researchers who have vague reports (minus the PoC) but are still adamant they want a CVE trophy, where essentially they've run a third-party tool that says "there might be a problem here, not 100% sure".<p>I'd love to hear your advice on this. What could be done to make this situation more tenable?<p>Off the top of my head:<p>* bump up the security content on our website so it's more obvious what we're looking for (and by extension, what we're not looking for)<p>* learn how fuzzers work and do the fuzzing ourselves<p>What else might work?