🌆Security Review Period
The security review period as determined by the SOW comprises the bulk of the engagement process
The security review period as determined by the SOW comprises the bulk of the engagement process
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:
Review Repository
Pull Requests (PRs)
Comments
Issues
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.
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.
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.
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.
