REVIEWER SUMMARY AND FILTERS
Last updated
Was this helpful?
Last updated
Was this helpful?
The Reviewer results are displayed using a combination viewing panes with filters.
The window is divided into 3 panes. At the top left is the Filter by Directory pane. Below that is the Filter by Category pane. Finally, to the right of both of the filter panes is the Fixes pane.
The top portion of the Fixes pane displays a quick summary of the results. The Session number, the total number of fixes produced by the analysis is shown along with information about which fixes have been selected for display. At launch, all fixes are displayed by default.
The branch name that was the subject of this analysis is also displayed. More importantly, there is an additional branch name displayed. When you accept and then apply fixes, the Reviewer will create Git commits and apply them to a new, temporary branch in your repository. This allows iCR for Python to automatically update your source code in a fashion that allows you to prepare and review pull-requests before merging them into your actual project branch. In this example, the temporary branch is named: iCR-master-20220520000756.
The tabs summarize the states of the various fixes. When the Reviewer is first launched following a fresh analysis, all the fixes generated are accounted for in the Total box (92 in this case). Rejected bugs from previous sessions are counted in the total number of issues, but only the unresolved issues are counted in the Unresolved tab (91 in this example). A discussion of rejected bugs is detailed in Section 6.4.5. The other states of a fix are:
• Accepted – This fix has been approved for future application to the code base • Rejected – This fix has been rejected • Manual – There were conflicts in accepting all of the fixes so some manual intervention will be required • Fixed – These are fixes that have been accepted and applied to the code base. Their state can no longer be changed
Note that each of the above tabs will show the total number of fixes in that state. If there are no fixes in that state, the tab will be inactive. How the state of a fix is modified will be described in a later section.
Up to 10 fixes are presented at any one time. The bottom of the Fixes pane shows the number of pages of fixes available for review and allows navigation across the pages. Also, the summary bar at the top of the page will not scroll off the top of the pane keeping the summary and the various state tabs available all of the time.
Each fix is identified with a unique Fix ID to help to distinguish each fix as it moves through the system. In this example below, the fix ID is SMI-PyCCEV-1-1. There is a title for the fix: Check CSRF Exempt View, and the category within which this fix belongs: Security Misconfiguration Issues.
There is also a description of the fix which includes the file name where the fix was produced: views.py. Other errors might also identify the relevant method or class. This information makes it easier for you to find the specific place in the code where the fix is being applied.
Also notice that some of the text is highlighted with hyperlinks. The links help you to understand the problem in more detail and to understand the suggested fix. In this example, clicking on the Cross-Site Request Forgery link will take your browser to the OWASP documentation describing the impact of CSRF attacks.
In the top right corner of the box is an icon that presents OpenRefactory’s view of the severity associated with the bug being displayed. There are three levels of risk being assessed:
• High • Medium and • Low
Higher severity bugs represent flaws that represent greater potential vulnerabilities if not corrected.
