Why Immunefi Standard?
The Immunefi Standard Badge sets the bar for all projects on the Immunefi platform. The badge icon indicates to whitehats that your project is following all of the best practices outlined in the criteria below. In doing so, it provides whitehats with additional reassurance regarding the reliability and efficiency of your project, which makes them more likely to submit reports to your program.
When your project receives the badge, it will appear on the Explore Bounties page, as well as your bug bounty page.
Criteria
In order for your project to receive the Immunefi Standard Badge, you must adhere to all of the following criteria, unless it is inapplicable to you. If you have met the criteria but you do not have the badge, please contact us so that we can review your program and award you the badge.
Note: Some projects received their badges prior to the release of the updated criteria below. These projects will be asked to meet the updated requirements in the near future, but they will keep their legacy badges for now.
Critical Theft of Funds Primacy of Impact Adherence
Projects must have a Primacy of Impact of impact policy applied for at least the “Direct loss of funds” for Blockchain/DLT bug reports and/or (must be “and” if they have both) “Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield” and “Protocol Insolvency” for Smart Contract bug reports. This further ensures that your bug bounty program truly protects your project from the loss of funds.
Impact-Focused Severity Classification System
Projects must have an impact-focused severity classification system in place, as seen in the Impacts in Scope section. Having an impact-focused severity classification system allows for a clear and objective assessment of your program by whitehats, and it simplifies any report validity evaluation that may be necessary. Our research shows that one of the main reasons why whitehats hesitate to work on a bug bounty program is ambiguity and lack of clarity. By having such a section, you greatly reduce ambiguity by clearly outlining what impacts you will accept.
If the section only contains impacts from the latest severity classification system, but not necessarily all of them, then you are automatically considered as satisfying this requirement.
Signed Statement of Work
You must have signed the Statement of Work (SOW) contract. This ensures that you have agreed to our operational standards such as SLAs involving responses, thus addressing potential responsiveness concerns. Signing the SOW also indicates that you have agreed to have the bug bounty program as a contract itself, thus further reducing uncertainty among whitehats regarding the content of your bug bounty program.
10% Funds at Risk Scaling Reward System for Smart Contract Critical-Level Rewards
If your project has a scaling system for smart contract critical-level rewards, then it has to reward at least 10% to satisfy this requirement. We have found through our research among whitehats that 10% of the funds at risk is generally an acceptable additional limitation to a published reward amount. Therefore, we recommend this as a standard throughout bug bounty programs on Immunefi for smart contract critical bugs with a scaling reward system in place.
If your project does not have a scaling reward system based on the funds at risk but rather provides a flat reward no matter how much is stolen, then this criteria is considered as inapplicable.
If your project has a hard cap on the reward, you do not fail at satisfying this criteria.
Minimum Critical Reward Amount of USD 50 000 or 25% of Maximum Critical Reward, Whichever is Lower
If your project has a scaling system for critical-level rewards, then it has to reward at least a minimum of USD 50,000 or 25% of the Maximum Reward, whichever is lower. We consider this to be a best practice because whitehats shouldn’t be incentivized to squat on a bug report in order to get a reasonable reward. Through interactions with whitehats within and outside our community, we’ve found this to be a satisfactory minimum amount and minimum amount ratio in order for them to refrain from squatting on a report.
If your project does not have a scaling reward system based on the funds at risk but rather provides a flat reward no matter how much is stolen, then this criteria is considered as inapplicable.
Known Issue Assurance
Your project has committed to disclosing known issues publicly and/or privately via a self-reported bug submission if such bug would be considered in-scope for your bug bounty program. Inability or failure to disclose a known issue would result in a bug report identifying that issue being considered valid and due 100% of the reward as per the bug bounty program.
This process is to simplify all known-issue-related bug report rejections by allowing projects to cite a self-reported bug report with the report number when rejecting a submission as a known issue. If the whitehat has doubts, Immunefi can also verify that it is, indeed, a known issue, and the case could be resolved quickly and smoothly. Having known-issue-related rejections processed in this manner is thus a best practice, especially given that it is already discouraging on its own to find a valid report only to be turned away from a reward since it was known previously.
Responsible Publication Category 1, 2, or 3
Your project has agreed to a Responsible Publication category. By selecting a category, it becomes clear to all parties with regards to the terms of publication of a submitted bug report through Immunefi, thus clarifying the process required for any public disclosure and demystifying uncertainties.
Agreeing to any of the Responsible Publication categories satisfies this criteria.
Agrees to the Disclosure of Bug Bounty Program Operations Metrics
Your project has agreed to publicly disclose data of its operational metrics. These data points are the total amount paid out (in USD) and the average resolution time. By being transparent about response and resolution times, you communicate more clearly to whitehats what they can expect when they submit a bug report to your program.
Changes to the Criteria
Immunefi reserves the right to modify the criteria to receive and maintain the Immunefi Standard Badge. If any additional criteria are introduced, or modifications are made to existing criteria, existing badge holders have up to 90 days from the introduction of the new badge criteria to adhere to them in order to maintain badge recognition.
Exception Cases
Immunefi may, at its discretion, grant exceptions to certain criteria on a project-by-project basis, especially as we continue to develop the Immunefi Standard Badge further.
Comments
0 comments
Article is closed for comments.