3

I work for a small company and for our webapp, we want to offer bug bounties for vulnerabilities reported with monetary rewards based on criticality. Problem is we only have a limited overall budget and dont want to promise anything we cannot pay. My question is: how to best phrase out the terms for our bug bounty project.

Let´s take some imaginary numbers and an imaginary situation to describe the problem. Say the overall budget is 1000. I would offer 200 for a critical vulnerability reported.

Now I start the program and receive ten reports coming in one after another, report A, B, C, ... Each report contains a critical vulnerability, as claimed by the reporter. Now I take my time and check each report and if it is valid. In the mean time, I get more reports. Let´s say, I have validated the first 5 ones as being critical. My budget would be exhausted in paying the reporters, but I still have more reports with valid vulnerabilities.

What is the best approach here from your suggestion? Splitting? Paying based on "first in"? I don't want to bait people with false promises, but I also do not want to drain our finances. I would stop the reward announcement of course once I realize that the budget is running out.

Also, a related question: What is a good practice if two reporters claim the same vulnerability? Do you reward both, do you split the bounty or only reward the first one in this case? I mean someone could just report under a different name with a slightly modified POC...

Thanks for your thoughts

Chimarr
  • 53
  • 3
  • I'd say this is a better question for an economist over at https://economics.stackexchange.com/ who deal with distributing rewards all the time. It has little to do with information security directly. – Steve Sether Feb 11 '20 at 19:45
  • 1
    @SteveSether I mildly disagree in that this is the sort of thing people in this group may have already dealt with, and may have answers that reflect direct experience with this problem. I'd rather practical feedback from someone who's run a bug bounty than the most expert experience from an economy wonk (who has lottery models or whatever in their head, but doesn't know what a bug bounty is). – gowenfawr Feb 11 '20 at 19:59
  • @gowenfawr I didn't vote to close it, but I maintain this is a more general problem of rewards and money. Economists have better ideas on how this sort of thing works, and can have a far broader perspective on what motivates people (which is what a bug bounty is about). I don't think there's too many people with real practical experience in bug bounties, which is when you make the problem "larger". – Steve Sether Feb 11 '20 at 22:18

1 Answers1

3

You are the vendor, so you make the rules. Just be clear about them.

Problem is we only have a limited overall budget and dont want to promise anything we cannot pay.

Then be clear about that. It's not uncommon for programs to do challenges/events where they pay special rewards for e.g. the first N critical reports, or pay extra for the best report submitted in a given time frame. So you could establish your budget as a "reward pot" from which you pay bounties until it's depleted. Or give rewards based on a ranking (e.g. monthly) - best report gets X, second best Y, ... This way you can keep your budget capped. Just make sure you clearly explain your reward scheme and stick to it.

What is a good practice if two reporters claim the same vulnerability? Do you reward both, do you split the bounty or only reward the first one in this case?

Always only reward the first report. (Double-check that you didn't mix up the timestamps.) Hearing that a report is a dup can be frustrating, but bug hunters know about this risk. Also, it's good practice to CC the reporter of the duplicate on the original, so they get proof that there's indeed an earlier report, and can follow the progress.

Some additional practices I've seen in real-life BBPs:

  • Start with low bounties and work your way up. You can state in the rules that bounties will be increased after the program's test phase.
  • If multiple reported bugs share the same root cause, treat and reward them as one.
  • If you notice many valid reports target the same component, temporarily exclude it from the scope (but still reward the earlier reports!) and conduct a manual audit before moving it back into scope.
Arminius
  • 43,922
  • 13
  • 140
  • 136