Pre-Impact Bug Monitoring

The Difference Between Immunefi’s Standards On Repeatable Attacks & Pre-Impact Monitoring

Immunefi’s standard on repeatable attacks determines a bug report’s payout amount based on a project’s capacity to respond to any specific repeatable attack.

On the other hand, Immunefi’s standard on pre-impact monitoring determines how any specific means of detecting a bug exploit & preventing the impact before it even occurs is factored into a bug report’s evaluation.

These are distinct factors in a bug report. For example, Immunefi’s repeatable attack standard will always apply to repeatable attacks, even if the project has no monitoring. And Immunefi’s pre-impact monitoring standards will apply even if the bug exploit is not repeatable. As well, both these standards could apply together to a single bug report.

Automated Means Of Blocking Bug Exploits

The term ‘auto-block tool’ in this article refers to any automated tooling which would detect a specific bug exploit before its impact is achieved & fully prevent it.

In general, if a project can objectively prove that an auto-block tool would prevent a bug exploit with 100% certainty, then Immunefi considers this a valid reason to downgrade the bug report’s reward amount by one severity level.

Immunefi still recommends that projects reward bug reports which would be automatically prevented with 100% certainty because:

1. There may be variants of the exploit that the auto-block tool would not catch.
2. There may be costs or damages caused by using the auto-block tool which are avoided by fixing the bug.
3. When the code is updated in the future the bug exploit, or variants of it, may no longer be prevented.
4. Despite the existence of the auto-block tool, there is still an impactful bug in the code which needs to be fixed.

However, if a project does not fix the bug, then Immunefi considers it reasonable for the project not to reward the bug report.

Automated Means Of Detecting Bug Exploits

Immunefi will evaluate bug reports on a case-by-case basis if by a combination of human action in response to an automated bug exploit detection tool, the bug exploit would be prevented. This may or may not be sufficient reason to downgrade a bug report.

In general, in order to downgrade a bug report for this reason, projects are required to provide 100% objective certainty that they would fully prevent the bug exploit. Projects are also required to provide objective proof that an automated bug exploit detection tool would detect the specific bug exploit with 100% certainty. 

Some factors that Immunefi considers when evaluating a bug report of this type are whether the required human action:

1. Can be executed unilaterally by any one of multiple individuals who would all be alerted by the automated bug exploit detection tool, or, requires multiple individuals in order to be executed.
2. Is fast, simple, and easy to execute, as well as being harmless to the project and its users, or, is slow, complicated, hard to execute, potentially costly or harmful to the project or its users.
3. The time between when the bug exploit would be detected and when its impact would be achieved.

Cases of this type are often highly complex and subjective, and so will always be evaluated on a case-by-case basis. Request mediation from Immunefi when you need help with such a bug report.

Non-100% Certain Means Of Detecting Bug Exploits

In general, if a means of detecting a bug exploit before its impact is achieved cannot be done with 100% certainty, then it’s an invalid reason to downgrade a bug report. This includes human means of detecting bug exploits, such as the project’s community, developers, or privileged addresses like Validators noticing the bug exploit.

However, exceptions may be made. Such as if a project has historically detected the specific type of pre-impact transaction involved in a bug report and successfully executed the correct action in time to prevent its impact.

Requirements For Proof Of Automated Detection/Blocking Tools

Immunefi requires proof that the project’s automated bug exploit detection or blocking tool would catch a specific bug report in order for that bug report’s reward amount to be downgraded. 

Immunefi also requires that the project share the proof with the whitehat and/or Immunefi (in certain cases) who submitted the bug report under the principle that private transparency is necessary for trust and fairness in the process.

FAQ

1. Q: If a project’s auto-block tooling would catch the bug’s exploit with 100% certainty, then is it a known issue?
   
   A: No. Known issues refer to when a specific vulnerability and its impacts are known in detail in advance. On its own, an auto-block tooling does not indicate whether any specific bug was known in advance.
   
   If the bug is a known issue, then the burden of proof is on the project. See this article for more details on how projects can prove a bug is a known issue.
   
   
2. Q: If Flashbots, a private mempool, or other means can be used to fully bypass the project’s detection tool, can it still be used to downgrade a bug report?
   
   A: No. If such a means could bypass the detection tool, then it’s not considered effective enough to allow the attack to be prevented.