Best Practices: Primacy of Impact

Due to the complex nature of creating bug bounty programs for projects, there are often edge-case bug reports that don’t fit neatly within the program rules. An example of this would be when a reported bug affects an asset that is not in scope, but the overall impact is in scope and the damage is extreme. Say, a whitehat has found a vulnerability that causes a direct loss of funds impact through an asset or contract not listed as in scope for the project’s Immunefi program. 

According to the rules of the bug bounty program, the above example would not require the project to pay the whitehat and so disclosure of such discoveries is disincentivized. That outcome contradicts the primary objective of most programs, which is to protect at-risk funds and product integrity, but it is the inevitable result of prioritizing rules (such as in-scope/out-of-scope assets) over impact. Such high impact vulnerabilities fall between the cracks of a bug bounty program.

This goes against the spirit of our platform and it leads to poor outcomes for all involved. Nor is depending on whitehat goodwill an effective solution to this issue; If a whitehat helps a project with demonstrable impact, but they are refused payment because of a technicality, that whitehat is unlikely to continue hunting bugs—they may even turn blackhat.

Primacy of Rules vs. Primacy of Impact

The solution to this dilemma is to shift from a primacy of rules policy, to a primacy of impact policy.

A primacy of rules policy means that all bug bounty reports are judged solely against exactly what is published on the bug bounty program. If the report does not fit within those rules, it is out of scope and, therefore, not eligible for payment, regardless of impact. This is how most programs work today. Primacy of rules programs will typically require that many conditions be met for a report to be eligible for payout (asset in-scope, impact-in-scope, no rules broken, etc), and, for this reason, many whitehats are disincentivized from hunting on these programs.

In contrast, a primacy of impact policy means that bug bounty reports are judged based on the impact of the reported bug, regardless of assets-in-scope. If the reported asset is technically out of scope, but the impact is within scope, then the whitehat will be fully compensated. The impact, or potential damage (as defined and decided upon in advance by the project) becomes the central and overruling determinator of report validity. Open programs like these maximally incentivize whitehats to invest in hunting on them because they will be rewarded for especially creative or novel exploits.

Best Practices

A primacy of impact policy is the most effective approach for protecting your project. Under this policy, whitehats are incentivized to report any vulnerability with in-scope impacts, which means that your money will be more secure. This effectively covers any gaps or unforeseen issues that might exist in the specific wording and rules of your bug bounty program by letting hackers know that, above all, you care about finding vulnerabilities that could result in critical impacts (be it loss of funds or others). Furthermore, projects that adopt primacy of impact for their bug bounty programs will receive more high quality submissions because whitehats prefer projects that are open to rewarding unexpected sources of vulnerability.

Therefore, if a Blockchain/DLT or Smart Contract impact submission affects an asset that is not included in your bug bounty program, but the impacts are in scope, we strongly encourage you to accept it as in scope for your program and pay the bounty according to the appropriate severity level.

If, instead of primacy of impact, you would like to abide by a primacy of rules policy, this must be clearly stated in your bug bounty program. However, know that hackers will be less inclined to submit to your program if you choose to do so. 

You can read more about updating your bug bounty program here.