Reviewer summary and filters

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 Java 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-20220629172635.

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 Unresolved tab. It shows the total number of fixes (29 in this example). 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 other sections.

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 SDE-RRG-1-1. There is a title for the fix: Weak Library Usage, and the category within which this fix belongs: Sensitive Data Exposure.

There is also a description of the fix which includes the file name where the fix was produced: InventoryBehavior.java, the particular class: InventoryBehavior and the method: getTempHotBarSlot. 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 cryptographically strong random number generator link will take your browser to the Java documentation on how to use the SecureRandom class. Similarily, the links CWE-332 and CWE-336 will take you to more information on these Common Weakness Enumerations (CWE) that are identified in this fix.

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:

Higher severity bugs represent flaws that represent greater potential vulnerabilities if not corrected.