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.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.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".I'd love to hear your advice on this. What could be done to make this situation more tenable?Off the top of my head:* 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)* learn how fuzzers work and do the fuzzing ourselvesWhat else might work?