> Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities w

> Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. It is different in that looking for vulnerabilities in code only costs you time, trying to introduce vulnerabilities costs the other person's time as well, and often producing vulnerabilities scales much better, e.g. you could write some tool that mails them patches, while they'd have to individually judge the merits. > There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. I don't think so. The issue isn't so much with trying to get code reviewed, it's with wasting people's time. That they did so by trying to introduce bugs is just the icing on the cake. If you get consent, you can have all your tests and strengthen the infrastructure, without eventually breaking the system because every other "researcher" submits bogus code every day in hopes to have one slip through and write a paper on how they proved that project x is exploitable. I've noticed the same with general bounties. When you have a security.txt or are on hackerone etc, you'll get lots of useless automated submissions that are wasting your time. Once that happens, you'll either shut down the program, or start rejecting reports automatically which includes the possibility of a false positive.