Define your targets and rewards based on your security objectives
Scopes and rewards are at the core of a Bug Bounty program:
- Scopes: What should be tested?
- Rewards: How much you are willing to pay for a valid finding?
Scopes
The scope is the first step of any Bug Bounty project : What should be tested?
You must list - as exhaustively and precisely as possible - all the assets that are in the scope of your Bug Bounty Program.
Scopes can be of different types: web application, mobile application (either iOS or Android), API, desktop application, IP address, firmware, IoT devices, - pretty much anything that is potentially vulnerable.
Make sure that you have identified all the components and assets for a given app or service.
For example: is there an API? Authentication is managed on a separate subdomain? Should it be part of this program?
Once a scope is listed in your program, it means that you encourage hunters to test it (in regards and respect of your rules) and can expect to be rewarded if their finding is eligible.
In order to define the scope of your program, you will see a dedicated section when you are editing a program:
By default, anything that is not listed in the scope, should be understood as out-of-scope. If you have more specific exclusions to mention, it is also important to list it.
Rewards
You will define the maximum reward for a given severity level.
When you receive a report, if it is reproducible, valid and eligible (based on your rules and scopes), you will assess it and set its CVSS score. The reward for this report will be calculated based on final CVSS score and corresponding reward grid.
It is possible to specify security requirements for each scope of your program.
It is a way to differentiate different levels of requirements, risks, maturity or complexity among the scopes of a given program.
For each security requirement that you selected, you will define the corresponding reward grid:
Once the editing is complete, it will appear to the hunters as in the below screenshot:
