For audit competitions (AC) with code deployed to mainnet, code cannot be frozen because the project may need to immediately mitigate severe bugs in live code, or otherwise halting development is unfeasible.
To provide a good security researcher (SR) experience and ensure Immunefi can accurately triage known issues and duplicate bug submissions, we require detailed changelogs whenever code changes are released during the audit competition.
Development teams are expected to adhere to the following guidelines:
Immediately Disclose Code Changes:
- After a code change is deployed, such as a critical bug fix, share the following in Immunefi’s Discord channel for this program & with Immunefi directly:
- If it is a bug fix, then provide a detailed explanation of the bug and proof of its resolution (typically a pull request).
- If it is a code change unrelated to a bug, then provide an explanation of the code change, the critical need for it, and proof of its implementation (typically a pull request).
- Always, share a link to the latest commit or branch which reflects the latest changes. Unless the links to your assets in scope already include the code changes.
- If it is a bug fix, then provide a detailed explanation of the bug and proof of its resolution (typically a pull request).
- The disclosed bug will now be considered a publicly known issue and out of scope for future submissions.
- Immunefi will immediately include the information on the program’s page and repeat the information to SRs.
Report Validity:
- Duplicates bug submissions and privately known issues are valid and in scope until the bug is made public.
- If a bug fix can be bypassed, the associated bug which bypasses the previous fix is considered new, valid and in scope.
- If a code change unrelated to a bug introduces a bug, the introduced bug is considered new, valid and in scope.
In the rare exception where a bug fix is made public but cannot be simultaneously disclosed publicly, the bug will be considered a known issue and the project can delay disclosing the code change until the fix is deployed. This is to prevent ‘issue snipers’ from stealing other SRs bugs.
Development teams are expected to fully comply with these guidelines out of respect for SRs, and to ensure their time is not wasted reviewing out of date code.
Comments
0 comments
Article is closed for comments.