Welcome to the Immunefi Bug Bounty platform! This article provides a brief overview of how to process bug reports and reward payouts. There are also links to further reading in each section if you have additional questions that are not answered here.
Using the Dashboard
Before you try your hand at processing a bug report, we recommend that you watch the Immunefi Dashboard Basics video.
|Escalations and Self Triaging||All bug reports will be escalated to you for review and self triaging (except spam). Immunefi will automatically recognize spam and not escalate it to you, unless you choose to turn off the automated filtering feature. You can see all the submissions marked as spam and decide if it is worth re-evaluating them.|
|Communications With the Whitehat & Asking Immunefi for Help||Projects & Whitehats discuss bug reports directly using the Immunefi dashboard. Immunefi can help when mediation is requested by the Project or the Whitehat. It is expected from all parties to maintain communication on the dashboard at all times.|
|Advancing Dashboard Statuses||Projects use Quick Action tools to advance bug statuses forward to resolution.|
|Changing Dashboard Severity Levels||
Projects can lower or raise severity levels independently by providing a valid reason to the whitehat, who has to agree or disagree with the project assessment. Note that a whitehat can request Immunefi to review in case they feel a submission is being improperly assessed by the project.
|Issuing Payments to Whitehat and Immunefi||To confirm payouts and provide transparency as well as trust, projects must provide transaction IDs directly in the dashboard upon payment.|
|Re-opening Bug Reports||
Projects can request Immunefi to re-open bug reports if they have been closed incorrectly.
Immunefi will run all bug reports through our automated filtering process to prevent obvious spam from reaching your inbox. Reports that make it through this process will be escalated to you for self triaging. This means that your team will need to review the report to determine whether or not it is valid or invalid.
If you would like to turn off automated filtering and personally review all new submissions, you are free to do so. You can read more about activating/deactivating automated filtering here.
|What do I do if...||Action|
|The bug report is valid.||Use Quick Actions to advance the status of the report.|
|The bug report is invalid.||Reply to the whitehat with a rationale that explains why the report is invalid. Mark the report as “Closed.”|
|There is not enough information for me to determine whether or not the report is valid or invalid.||Reply to the whitehat with your questions. Once the whitehat responds, you can use the information to determine whether or not the report is valid.|
Advancing Report Statuses
We’ve created a Quick Action feature to make advancing the status of bug reports easier and more efficient. When you select a Quick action, template text will be auto-populated for you in the 'Custom Reply' field and the status of the report will be updated (if applicable). This will allow you to quickly and effectively communicate with whitehats and advance reports through review stages until they are brought to resolution - either in a Closed or Paid status.
You can read more about Quick Actions here.
Changing Report Severity Levels
At Immunefi, we use a vulnerability classification system based primarily on a vulnerability’s impact and likelihood of exploitation. You can find a more detailed explanation of our severity classification system here.
If you disagree with the severity of a bug report, you have the power to lower or raise the severity level by providing a valid reasoning to the whitehat. If the whitehat agrees, then the severity level can be changed. If not, the whitehat may request mediation from Immunefi to resolve the issue.
It may be acceptable to change the severity level in the following instances:
- Uncommon or incorrect action must be taken by the victim
- Uncommon or incorrect action must be taken by an user with escalated privileges
- Attacker needs escalated/admin privileges
- Attacker needs key compromise
- No funds at risk
- Attack requires repeated interaction over a long period of time (project may notice)
- Attack requires adjacent network access or MITM network access
- Attack requires physical access to the victim's computer
- Attack requires brute-force complexity of over 40 bits
You can read more about changing severity levels here.
Requesting Mediation from Immunefi
While we hope that projects and whitehats can work together to resolve reports, we understand that sometimes a neutral third party is necessary to settle disagreements. In the event that you cannot resolve an issue together, align on impact, severity and/or reward level, or in the event a whitehat becomes threatening or is breaking a rule of the Immunefi platform, you may add an Immunefi mediator for help.
|If Immunefi is not subscribed to the bug report…||Click the “Request Help” button at the bottom right of your submission page and select one of the reasons provided on the list.|
|If Immunefi is subscribed to the bug report…||Reach out to us using the “Comments” section by replying to “[Your Project Name] and Immunefi” and explaining why you are requesting mediation.|
For more information on how to request help from Immunefi, you can read the “How & When to Request Help” article here.
Bug reports are considered resolved when they are either rejected as invalid (marked with the Closed status), or paid out by the project (marked with the Paid status). Note that the report cannot be considered Paid until both the whitehat bounty and the Immunefi fee are paid.
Reports can also be resolved when the Service Level Agreement (SLA) is not tied to fixing the bug, so the project either closes or pays within the SLA timeframe.
Issuing Payments to Whitehats
Payments are sent directly from projects to whitehats. The wallet address of the whitehat, shared at the time of submission of the bug report, will be displayed on the right side panel of the bug report itself.
Always confirm with the whitehat their wallet address before sending any payment. When advancing from Confirmed to Paid status, a template will auto populate for you and prompt you to reconfirm the whitehat's wallet address.
Some projects choose to make KYC (know-your-customer) info a requirement for whitehats who hunt on their bug bounty programs. If you choose to do this, know that we do not conduct any KYC verification on our platform. All KYC verification is strictly between you and the whitehat.
You can read more about issuing payments to whitehats here.
Issuing Payments to Immunefi
The final stage of a Paid report is to issue the Immunefi 10% fee.
The 10% fee is calculated based on the amount sent to the Whitehat in the currency/coin used to pay them; the actual amount sent and not the outstanding rate at the time the transaction to Immunefi is sent.
Once you submit payment to the whitehat and mark the submission as status 'Paid', you will be sent instructions to pay the Immunefi fee.
You can read more about issuing payments to Immunefi here.
Re-opening Closed Reports
If you believe that a report has been incorrectly closed, it is possible to re-open the report. To do so, you simply need to click the ‘Re-open report’ button at the bottom of the report page on a closed report.
You can read more about re-opening closed reports here.