🌆Security Review Period

The security review period as determined by the SOW comprises the bulk of the engagement process

Security Review Period

The security review period can be considered an interactive process between clients' and their review teams as communication is often abundant when contextualizing the target scope in light of attack vectors.

Regarding the security review process itself, the workflow is detailed in the following components below within the context of Github:

1. Review Repository

2. Pull Requests (PRs)

3. Comments

4. Issues

Review Repository

Within the security review repository, researchers will leave comments that the client can view and interact with asynchronously. The repository is organized into various branches, reflecting the quantity of files under review.

Structure:

• Different branches are proportional to the number of files in scope.

• If a file has more than 500 lines of code, it is often divided to minimize latency in Github API requests during the retrieval of issues for copywriting.

Pull Requests (PRs)

Under the client's PRs, they can see the files under review and instantly get a glance at what is currently being worked on by the security review team. This is to serve as oversight for both the core team and client team to be aware of the security review's progress.

Comments

Within the respective PRs - the client and core team can track comments which will serve as the main medium by which the core team will be addressing code-related matters, raising questions, and initiating technical discussions.

Comments will serve effectively to facilitate the bulk of interactions between the review team and client regarding to the security posture of the code itself:

• The client is encouraged to actively participate in discussions, capturing valuable insights from the auditors.

• The incremental approach of commenting on code as discoveries are made facilitates the client's team in addressing and clarifying issues early in the process.

• Once a conversation concludes, a formal issue is created with the client's commit fix (or a comment explaining a decision not to fix), and any relevant discussion between the client and the auditors.

• Regular monitoring of the security review repository for notifications is highly suggested.

Issues

Once a finding from a pull request's comments is confirmed and finalized by the client, it is turned into a Github issue. The review team will then attach an accompanying severity and/or status label as shown below:

Severity

Severity is determined as follows:

Severity level	Impact: High	Impact: Medium	Impact: low
Likelihood:high	Critical	High	Medium
Likelihood:medium	High	Medium	Low
Likelihood:low	Medium	Low	Low

Severity will fall under the following labels:

• Critical Risk

• High Risk

• Medium Risk

• Low Risk

• Gas Optimization - opportunity for reduction of gas costs

• Informational - room for optimization not impacting security directly

Status

• Acknowledged

• Fixed

• ReadyForReport

Upon reviewing an issue, they are reviewed and labeled as Fixed or Acknowledged, contingent on the client's response. These issues will eventually become part of the final report.