When participating in a Code4rena mitigation review, your objectives are to:

• Review all mitigations submitted by the sponsor, and assess whether they’re sound
• Share your feedback for each mitigation — which typically corresponds to a High or Medium risk finding in their most recent C4 audit
• Flag any newly-introduced bugs or vulnerabilities

Questions? Ask @Cloud Ellie.

Participation and no-shows

Any warden who is unable to participate in an invitational audit MUST inform C4 staff within 24h of the audit launch at the latest, so that an alternate can be arranged.

Failure to provide notice of non-participation will have a negative impact on your ability to participate in future invitationals and other certified warden opportunities.

Before you begin

• C4 staff will ensure that judging is complete on the “parent” audit before the mitigation review begins.
• The sponsor is instructed to create a single branch in their own repos containing all related PRs. There will be a separate PR per finding, e.g. mitigation of H-01, mitigation of M-03, etc. (This way the wardens can review all discussions related to the vulnerabilities that were found.) Though we do understand that sometimes the findings are interrelated and stem from a shared problem in the code, in which case a shared PR is fine.
• All warden(s) assigned to the mitigation review should have the certified Security Researcher (SR) role, so they can view the findings for the preceding / parent audit.

What to include

• Commentary on each High and Medium finding’s mitigation

  <aside> ⚠️ Occasionally, QA fixes are also included in the scope of mitigations to be reviewed. The repo README will always outline the complete scope of mitigations to be reviewed, and should be considered the definitive source for any questions about scope.

  </aside>

• Additional HM findings you discover

• Depending on the type of mitigation review (Solo or Versus), please refer to the instructions below as well.

What not to include

• There’s no need to provide a disclaimer regarding completeness or liability; Code4rena’s agreements with sponsors, and our reports, already include disclaimers and language about limitations. (For example, here.)
• Some HM issues from the preceding audit may be “acknowledged” by the sponsor; i.e. they do not intend to fix the issues for various reasons. These should be listed in the “Out of scope” section of the Mitigation Review repo README file and a review should not be submitted for these.
• New low-severity / non-crit / Gas findings: you’re welcome to submit these as a courtesy, but there’s no need to do so.
• Vulnerabilities submitted during the preceding audit should not be submitted as new HM issues during the mitigation review. They will be considered out of scope and ineligible for awards. If a warden feels an issue from the preceding audit was overlooked or undervalued, it is recommended to look into submitting it to the sponsor via other channels (e.g., a bug bounty program).

Submission guidelines for mitigation reviews

1. Review each mitigation provided, and submit feedback on each one:
   1. For the in-scope mitigations, was the original bug fixed? In the “Mitigation status” dropdown, choose either Mitigation Confirmed or Unmitigated.
   2. In the “Mitigation of” field, select the original finding from the dropdown.
   3. If the mitigation status is Unmitigated, you must select the appropriate “Risk rating” of the issue, as well as provide links to the affected code.
   4. Your comments: please ****include the rationale for your assessment, and/or steps followed. Optionally, a quick screenshot or code snippet provides evidence that helps the sponsor and judge understand your conclusion.
2. Newly-discovered HMs (either missed in the previous audit(s) or caused by an attempted mitigation) should be submitted via the audit submission form, as usual:
   1. In the “Mitigation status” dropdown, choose New.
   2. In the field labeled “Mitigation of” please select the original finding from the dropdown OR leave blank if not related to a specific original finding.
   3. Select the appropriate risk rating
   4. For HM errors found within mitigations, please use the title "[reportId] mitigation error"
   5. Include Vulnerability Details as you normally would for highs/mediums.

• Want some examples of past satisfactory submissions? Click to expand!

<aside> ‼️ Important note: You must submit a mitigation review for every finding from the parent audit that is listed as in-scope for the mitigation review. So if the parent audit had 2 Highs and 3 Mediums that the sponsor mitigated and are in-scope, you must submit a review for all 5 issues, to indicate whether they have been successfully addressed. Incomplete mitigation reviews will not be eligible for awards.

</aside>

Judging, discussion, and awarding

Once the mitigation review competition ends, C4 staff will invite the sponsor team, judge, and participating wardens to view the findings.

The sponsor team will review and comment on the submissions concurrently with the judge.

Awarding works as follows:

• Participation pool: 30% of the mitigation review pool will be divided equally among all participating wardens who meet the following criteria:

  • submits a review of every in-scope mitigation;
  • all reviews are of sufficient quality.

  Please refer to the C4 docs for current judging criteria.

  To facilitate the integration of final mitigation statuses into the audit report, judges are requested to add a Mitigation label to indicate their agreement with either mitigated or unmitigated status. Please add this label to one issue within each set of duplicates. It's important to note that this label is solely for reporting purposes and does not affect the awarding process.

• The rest of the mitigation review pool (70%) will be distributed among newly-identified High and Medium risk findings or mitigation errors (all must be hard errors), using Code4rena’s standard HM grading and awarding rubric:

  • For newly-discovered HMs, judges should use the primary and duplicate functions as in any C4 audit.

• If no valid HM findings are identified, the remaining portion of the award pool is allocated to the participation pool

  <aside> ❓ What belongs in the 70% HM pool? The distinction between "mitigation not confirmed" and "mitigation errors and new issues" can be nuanced. Some suggestions from our judges as to what belongs in each category:

  Mitigation not confirmed (30% pool): sponsor tried to apply a fix, but the same issue remains; mitigation is not sufficient to address the issue cited.

  New issues and mitigation errors (70% pool): Mitigation created another High/Medium issue; any other High or Medium-risk issues discovered in the codebase.

  When in doubt: make your best assessment and include a note for sponsor and judge that you’re uncertain which pool is appropriate.

  </aside>

• QA issues may be submitted as a courtesy, but are not eligible for awards.

• Submissions judged as insufficient quality or spam are ineligible for awards.