Objectives

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

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.

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

What not to include

• Wontfixes: 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-critical findings: you’re welcome to submit these as a courtesy, but they aren’t eligible for awards
• 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.
   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 submission form as follows:

   1. In the “Mitigation status” dropdown, choose New.
   2. In the “Mitigation of” field, 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.

   <aside> <img src="/icons/warning_yellow.svg" alt="/icons/warning_yellow.svg" width="40px" />

   If you discover a new HM finding within a mitigation, you must also submit a review of the mitigation labeling it as Unmitigated.

   </aside>

• 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 are not eligible for awards.

</aside>