Part 2: A pragmatic guide to building your bug bounty program

Budgets and payments, and dealing with beg bounties

This is part two in a series which provides a pragmatic approach to starting your bug bounty program, targeted particularly at startups. In this post, we cover budgets, payments, and how to deal with beg bounties.

If you haven’t already, check out part one here, where we cover the tactical parts of setting up your bug bounty program.

So, how much should you pay?

One of the most difficult questions to answer when building a bug bounty program, is how much to pay for successful bug bounty reports. Obviously this changes as you scale, but as a general rule of thumb we try to balance the impact of the bug against the resources we have to reward findings.

A safe amount you could consider is something like:

• P1: Severe impact, such as account takeover — USD$10k
• P2: Major impact, such as account corruption or privilege escalation — USD$3–5k
• P3: Medium impact, such as minor data leak within an account or local account DoS — USD$500–2k
• P4: Minor impact, such as a known design issue which you are now able to fix, or exposed vulnerable low-criticality services your scanners missed — USD$100–500

You can scale these up and down as much as you’d like — for some organisations, a P1 may have a greater impact and your security team may have the resources and motivation to issue bigger rewards.

An alternative option I’ve seen is to ship people t-shirts and other company swag — however, I’ve found this isn’t as well received.

Sticking to a monetary reward is much cleaner and more appreciated by bug bounty reporters — once you take into consideration t-shirt design, printing costs and the time required, monetary rewards can often end up more cost effective.

Setting a budget

For a small or medium sized start up (< 1000 people), I would budget about USD$30–40k per year if you’re doing it yourself, or more if you’re using a bug bounty vendor. I would expect to have 0.1–0.25 people working on it throughout the year.

This is entirely subjective, so it can be helpful to view your program as fluid. With our bug bounty program, we can either ramp up (based on the measured impact from historical reports) or down (when we hit budgeted limits).

Getting stakeholder buy-in is key, so start by explaining the program and its benefits to your finance team.

Comparing the cost of running periodic penetration tests is a good way to approach this discussion — the output is different, but it makes progress against the same goal. As with everything in security, you’re comparing the risk of not discovering these findings, against the potential business cost to if they’re exploited by an adversary.

Once you get your program up and running, metrics become key to establishing your budget and reward amounts. Comparing the findings from your bug bounty program and penetration tests can help give you relative data on how much you should be spending compared to the benefit you receive.

Beg bounties

A term coined by Sophos and expanded in Troy Hunt’s Beg Bounty article, a beg bounty is someone submitting a low-effort, low-value report and “begging” for a reward.

While running your bug bounty program, you’re likely to receive a lot of beg bounties — these will typically involve some combination of the following:

• A person asking if you’ll pay a reward for security vulnerabilities they find (without telling you what you’ve found)
• A person emailing senior leaders and generic email addresses saying they’ve found a severe vulnerability in an attempt to cause panic
• Very low priority (non-)issues, such as scan reports of DMARC or SPF records
• Unvalidated and/or theoretical vulnerabilities
• Immediate ask for payment

With bug bounty programs rising in popularity over the past few years, so too has the amount of low-effort, bogus bug bounty reports (submitted to companies in the hopes of a reward).

I’ve also noticed these are getting increasingly automated.

Generally someone will find your company’s website, (optionally) search to see if there’s a bug bounty program, throw your domains and URL into SSL Labs or dmarcian, and send an email saying something like:

I have found a serious vulnerability in your website that will allow me to email anyone as your CEO. According to [OWASP | BugCrowd | similar framework] this is a [P1–4 | critical | severe] vulnerability that needs fixing. Please provide a bounty for this report.

Beg bounties can be an unfortunate time sink. At Airwallex, we’ve minimised this impact by setting up email auto-replies which link to our bug bounty program’s terms; explicitly stating which issues will not be rewarded and that we can’t always respond to low priority findings.

If you’re looking for a canned response to send out automatically, you can try modifying the below:

Hi there,

Thanks for submitting a report to our bug bounty program. Please ensure that you have read our <bug bounty terms>[https://linktoyourterms.here] as part of this submission.

We receive a high volume of reports and unfortunately cannot respond to all reports. Please note that we will not provide responses to any reports which:

- Do not follow our bug bounty terms

- Has an unvalidated vulnerability (except where validating the impact would cause harm to [your organisation])

- Consists of low-value findings commonly found using a scanning tool (e.g. SPF records, DMARC records, TLS/HTTPS algorithms and ciphers)

- Consists of vulnerabilities which rely on brute force or social engineering

If your report does not fall into these categories, please make sure you’ve provided details about the vulnerability you’ve found, including a full description of the vulnerability, the impact, and a proof-of-concept script.

Thanks!

- [Your organisation] Security Team

I’ve seen well-intentioned suggestions to help grow people who submit low value findings — pointing them at educational resources and helping them find better bugs. Although I like the effort in building the security community globally, your time is your most valuable resource and you need to remain aggressively focused on where you can have the most impact.

Instead, I’ve found building relationships with the bug bounty hunters — who submit valuable and interesting reports — is far more valuable. I’ve covered this in more detail in part three (coming soon).

This is the second entry in a three-part series on starting a bug bounty program. Continue reading Part 3: The value in building relationships with bug bounty reporters, where we cover how your relationships with bug bounty reporters can amplify the quality and consistency of reports.