Self Triaging Overview

This article will outline the overall process for assessment and self triaging best practices. In the next sub tutorials, you will see how to specifically self triage Web and Smart Contract reports. Please use the text as a guide to ensure your self triaging and assessment process is complete before validating, invalidating, or reaching out to the whitehat for more information.

Please note the following:

• We provide 'automated filtering', which means you won't get outright spam escalated to you 
• We provide as much help as possible in mediating bug reports, pending resource availability 

Where Immunefi's work stops

• Immunefi’s platform excludes web reports if only smart contracts are in scope.
• Immunefi does NOT do self triaging for your program.
• Immunefi does NOT determine the validity of a bug report.
• Immunefi does NOT determine if the PoC works.
• Immunefi does NOT determine if the suggested fix works.
• Immunefi provides as much help as it can in mediating bug reports, dependent entirely on resource availability.

We will still ask you to double check the reports that are filtered by the automated filtering system so that you are 100% confident that our spam filtering works as you expect. In case of dissatisfaction, please get in touch with [e-mail]

General rules

1. If you decide to fix a bug, you must reward the whitehat, unless it is out of scope. If the bug is out of scope and you fix it, you do not have to reward the whitehat, but we suggest you do so out of goodwill to the whitehat community. 
2. At any point, if you have questions or doubts you can reach out the whitehat for additional info through the dashboard.
3. When closing a submission, always give a thoughtful reasoning to the whitehat.
4. If you see a whitehat running a PoC on mainnet, testnet or in web production, please inform Immunefi immediately.

When not to pay for a submission

There are a few scenarios when Immunefi considers it acceptable for a project not to pay for a submission:

1. Duplicated reports. You should only payout for the first report of any given issue.
2. Known issues. If you can prove and detail that you already knew about an issue.
3. Non-security issues. Things that are not security issues but that you fix (i.e. UI button flicking).
4. Not fixing the vulnerability. Regardless of severity, if you decide not to fix the vulnerability, you don't have to pay.