For what it's worth, when I was setting up the culture and values of Google's first bug bounty programs, I hammered "be magnanimous" into the reward committees. i.e. look for reasons to reward more, not less. Find the value in the information provided, even if the person is being a jerk. etc. I don't think this culture has changed. There are teams of people rooting for incoming reports to succeed, and they get excitement and joy from issuing large bounties (because this means Google security is getting stronger).
I deleted three sentences about this very topic in my earlier comment because it turned into an ugly rant, lol.
>Maybe the next evolution of these programs will be long-term contract relationships with trusted, successful vuln hunters
I'm actually somewhat surprised that bounty programs missed the whole 'gig workers are employees' issue.
The refusal to pay while fixing the bug in 48 hours shows a power inbalance. I fear this is where we are headed in the future as AI pumps out most code all of the remaining work comes in the form of contests where thousands spends 80 hours a week and the company (in the best case) will award one person with a cash prize small enough to not hit minimum wage.
Here's the "20 factor test" (condensed from Oregon's condensed version) the IRS uses for employee classification:
* Does the company direct where, when, and how the work is done? (You can hunt for bugs from any country in the world, whenever you want, using whichever tools you like.)
* Does the company require company-provided training to provide the service? (The first contact Google has from a bounty hunter can be the bug they submit, and Google will pay).
* Is the service directly integrated into the business the company provides? (No: Google doesn't provide bug bounty services to other companies, and is not in fact a bug bounty with a small search engine attached.)
* Does the company insist on a particular named person to do the work? (No; in fact, until they're actually paid, many bounty hunters are psueodonymous.)
* Does the company control who the provider hires to assist in the work? (Nope, you can hire your own team of people to assist with your bountying, and Google does not care.)
* Does the company maintain a continuous relationship with the service provider? (Nope, you can submit a bug in June and then come back next April with another one, or come back never).
* Does the company determine the schedule on which the work is done, or is the schedule flexible? (Google does not even slightly care what schedule you find bugs on, or even the timeline you use to report bugs on once you find them.)
* Does the company demand full-time hours? (Google doesn't set any hours for bounty hunters whatsoever.)
* Does the company demand that the service be provided on-site? (Bounty hunters work exclusively from their own facilities.)
* Does the company demand that the work be performed in a specific order or sequence? (No, you can look for any combination of bugs in any set of services using whichever set of tests you want to use, be they fuzzing or mitmproxying or scanning, in any order you like.)
* Does the company require regular periodic written or oral reports? (Indeed they do not.)
* Does the company pay hourly, weekly, or monthly, rather than by the project? (Bounties are paid by the bug.)
* Does the company defray expenses for the work? (Nope.)
* Does the company provide the tools and materials needed for the work? (Nope, bounty hunters BYO laptops and Burp Suites.)
* Does the company provide facilities, office space, etc for the work? (Google doesn't provide even so much as a Slack account for bug hunters.)
* Are the earnings from the work predetermined, or can the workers realize greater or lesser profits from the amount of work they put on? (Regardless of the hours committed to bug-hunting, bug hunters earn revenue based on the value of the assets they generate; if you come up with a technique to find dozens of XSS vulnerabilities in a couple hours, you'll make a zillion dollars per hour.)
* Is the relationship exclusive? (Of course not, bounty hunters work with multiple companies as a rule.)
* Can the worker make similar services available to the public? (Not only can they, but independent consulting is the norm for this kind of work.)
* (This is 2 bullets, condensed) Can either party terminate the relationship independently? (Yep.)
Bug bounty participants are not, as a general rule, classifiable as employees. People make noise about it because there's drama about Uber --- where the company exerts substantial control over how employees do the work, when and where they do it, where they check in with their cars, &c, and do so while providing the core service the company offers. Someone on a message board is going to try to suggest that Google is in fact a bug bounty program with a small search engine attached to it, but I mean, come on.
Well, I felt pretty screwed over after Google decided not to reward me for discovering CVE-2021-30560.
It's more helpful to analyze the situation from a game-theoretic standpoint. Bug bounty programs are a typical example of a cooperative game. If someone reports a security issue, they start the game by cooperating. Google can then choose to cooperate by paying a bounty or they can defect by refusing a reward. Like in the classical prisoner's dilemma, both parties can typically maximize their rewards by choosing to cooperate.
My case is a bit special. While I don't know the exact reasons why Google chose not to reward me, it's possible that they thought I would continue to cooperate even after they defected. But like most rational players, I chose to stop cooperating, which ultimately leads to the worst possible outcome.
Same goes for the dialogs with unhappy hunters who like 'proof' for the arguments that a bug / vulnerability is not there.
There is literally no financial incentive for me at all to not reward, au contraire actually.
But the transparency you're asking for is difficult to actually provide. Meanwhile, for a vendor at Google's scale, there is essentially zero upside to screwing over bounty hunters. At any realistic valuation for a vulnerability, these are rounding error sums to the business. In fact, the exact opposite incentive exists: these bounty programs are deemed to be performing well when they pay out more money, not less. The people managing these bounties aren't paying with their own money. They'd rather make you happy and encourage you to submit more stuff.
The two phenomena you describe here are real and common. But it's just simply the case that vendors are generally working through backlogs of issues, triaged by severity. If you're told your finding is a dupe of a private issue, it is overwhelmingly likely that it is. If you pay for every independent discovery of an issue, people game that; worse than the dead weight loss of the bogus bounties, you set up crazy incentives on your dev team to fix marginal issues because they're being gamed, rather than triaging according to real severity.
And, bounty hunters do turn up real bugs that aren't real security issues, but are still bugs. If those bugs are easy to fix, they're going to get fixed! You have the same weird gaming and precedent issues if you start paying out non-exploitable bugfix findings; you encourage people to find and report non-exploitable bugs, and you screw up the team incentives on what to fix.
I don't expect people to like any of this logic, because it boils down to "you should just trust the Google VRP people". But: you should. This isn't worth the cortisol. If it's driving you up a wall, maybe don't participate? There are other ways to market security bug finding skills. :)
If you've never worked triage on a bounty before, my guess is that you can't really imagine how terrible the median interaction is. Maybe the next evolution of these programs will be long-term contract relationships with trusted, successful vuln hunters that address some of these concerns by separating out the people who are good at this stuff from the median submitter (the median submitter invests 2 weeks trying to litigate whether copying a cookie out of the Chrome inspector and pasting it into curl constitutes an account takeover vulnerability).