How is the reward amount determined on different bug bounty platforms like Bugcrowd, HackerOne or Synack?
As a bug bounty program owner I can maybe define some rules for the rewards. What are the common, established rules and how do the different platforms support them?
A bug bounty program's rules should communicate the used criteria and process for determining bounty amounts as clearly as possible. However, bug bounty platforms usually don't constrain your program's reward structure or enforce fixed severity levels which you must adhere to. There are just too many cases that require some flexibility. That said, many program rules lay out tables of different tiers with baseline (and possibly maximum) payouts. The following are some common criteria to rank vulnerability submissions and determine adequate amounts.
Severity of the vulnerability. A more severe vulnerability should (obviously) pay more. A remote code execution bug is most likely more dangerous than XSS and so on. You can apply the Common Vulnerability Scoring System (CVSS) to quantify the severity of a given security bug. However, this may get tedious. Many program rules just set a rough list of tiers. E.g., Google's VRP distinguishes between remote code execution, file system/database access, security control bypasses, client-side code exec (e.g. XSS), and others. Similarly, the program of Uber makes use of several "security impact buckets".
Relevance of the affected application/component. This partially ties into the previous point. The same type of vulnerability may have a different impact on different sites or components. XSS on a static subdomain served over HTTP may not be as harmful as XSS on the main domain where users manage their accounts. As for a real-life example, Twitter's program distinguishes vulnerabilities affecting the Twitter core (e.g. on *.twitter.com) from all others. Google's VRP classifies applications as account management-related, high severity, normal, and non-integrated/lower priority applications, each with their own payout structure.
Maturity of the bug bounty program. A new program/scope should start with moderate bounties and increase payouts once the "low-hanging fruits" have been discovered and finding high-severity bugs becomes increasingly difficult. You should keep adjusting baseline amounts based on the reports you're receiving to pay fair bounties that balance the bug hunters' skill and time efforts, with your budget.
Quality of the report. Some programs pay higher rewards for well-written reports. This is especially common/relevant for client software where some bugs can be significantly easier to investigate and patch with more technical information and post-report assistance by the researcher. E.g., Mozilla's Client Bug Bounty Program states "Improving test cases post-submission, figuring out if an engineer's speculation is founded or not, or other assistance that helps resolve the issue will increase your bounty payout." However, for your standard reflected XSS in a web app, a simple proof of concept is often sufficient and a submission quality rating has no merit.
Broader context of the bug. Sometimes, a vulnerability submission has an impact beyond the initial report. It may reveal a larger issue or be more critical than the researcher anticipated. Or, on the contrary, multiple reported vulnerabilities may all have the same root cause and it makes sense to treat them as a single bug. These considerations may, too, warrant a payout adjustment.
(Some of these points are presented similarly in the SANS whitepaper Bug Bounty Programs: Enterprise Implementation, chapter 2.7. Also have a look at #2 of this instructive post on the HackerOne blog.)
...how do the different platforms support them?
Platforms generally let vendors choose the bounty amount freely. E.g. on HackerOne you can choose between pre-calculated amount levels or reward a custom amount.
(Image: HackerOne Docs)
HackerOne also provides an optional CVSS calculator which can be used to have a vulnerability's severity determined automatically.
... depends on the budget your company is willing to assign to the program. As mentioned above, you can start with low bounties and work your way up based on the reports received and bounties paid so far. It may help to look at the payout ranges of other companies that are comparable to your own business. The concrete financial considerations would be beyond this answer.
