Unified Language User Guides
iCR User Guide 5.0
iCR User Guide 5.0
  • Table of contents
    • Introduction
    • Overview
    • Authorizing Access to Your Source Code
      • Authenticating GitHub Cloud Access Using OAuth
      • Authenticating GitHub Cloud Access Using PAT
      • Authenticating GitHub Enterprise Access Using OAuth
      • Authenticating GitHub Enterprise Access Using PAT
      • Authenticating GitLab Cloud Access Using OAuth
      • Authenticating GitLab Cloud Access Using PAT
      • Authenticating GitLab Enterprise Access Using OAuth
      • Authenticating GitLab Enterprise Access Using PAT
      • Authenticating Bitbucket Cloud Access using OAuth
    • Using the Navigator
      • Connecting to the Navigator
      • Setting your User Password
      • Updating your User Information
      • The Navigator top banner
      • The Analysis Engine status
      • Selecting Your Source Code
        • Using a cloud-based VCS
        • Selecting your branch
        • Using a private VCS
        • Using a local project
        • Limiting the files to be analyzed
      • Integrating with your bug tracking system
        • Integrating with Jira - Define Your Project
        • Integrating with Jira - Authorizing Access for iCR
        • Integrating with Jira - Connecting with iCR
    • Using the Analysis Engine
      • Initiating an analysis
      • Monitoring the analysis
      • Interrupting the analysis
    • Reviewing your results
      • Reviewer summary and filters
        • Filter by Severity
        • Filter by Category
        • Filter by CWE
        • Filter by OWASP
        • Filter by Directory
      • Reviewing a fix
      • Accepting a fix
        • Accepting a fix when integrated with your bug system
      • Rejecting a fix
        • Rejecting a fix when integrated with your bug system
      • Undoing a fix
        • Undoing a fix when integrated with your bug system
      • Rejected fix history
      • Providing feedback
      • Applying the fixes
      • Cases needing manual attention
      • Comparing Analyses
      • Capturing results for printing or sharing
      • Ending a reviewer session
    • When you are complete
    • Integrating iCR Into Your CI/CD Workflows
      • Jenkins Workflow
        • Installing the plugin
        • Configuring the plugin
          • Creating a Personal Access Token
          • Copying Your Repository's URL
        • Viewing the Results
      • GitHub Actions Workflow
        • GitHub Actions Overview
        • Preparing the GitHub Workflow
          • Environment Variables
          • User Supplied Secrets
          • Setting the User Defined Secrets Values
        • Executing the Workflow
      • GitLab CI/CD Workflow
        • GitLab CI/CD OverView
        • Configuring the GitLab Script variables
          • Environment Variables
          • User Supplied Variables
          • Creating a Personal Access Token
          • Setting the User Defined Variable Values
        • Executing the Workflow
      • Multiple Workflows
    • Appendix – Language Specific Fixer Lists
    • Appendix - Sample Bug Listing
    • Appendix - Getting a BitBucket App Password for JENKINS
Powered by GitBook
On this page
  1. Table of contents
  2. Reviewing your results

Reviewer summary and filters

PreviousReviewing your resultsNextFilter by Severity

Last updated 3 months ago

The Reviewer results are displayed across 2 panes. At the left is the Filters pane. The filters provide a number of ways of both restricting what is available for review and to focus upon certain aspects of the results.

The width of the Filters pane is ajustable by hovering over the divider line. Once the horizontal scroll cursor appears, you may widen or shrink the width of the Filters pane as you prefer. Also, the Filters pane is scrollable such that if many of the filters are in use, you may scroll up and down to review your filter selections.

There are 5 filters available. Each of these is covered in their individually linked sections:

The filters work as the intersection of all selected filters. That is, from the chosen filters in each of the filter classes, if something other than Select All is clicked, then only items specifically chosen are displayed. An obvious example demonstrating this, is that if, under the Severity filter, none of High, Medium or Low are clicked and Select All is also not clicked, then zero bugs will be displayed even if other filter categories are selected.

NOTE: If there are no issues in one of the categories of CWE or OWASP, then this filter will not be displayed.

The right side of the window is the Results pane. This is where the rolled up summary results are displayed followed by the detailed results. The top section displays a quick summary of the results. The Session number and the total number of fixes produced by the analysis approved 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 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-20250114043648.

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 (130 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.

Each fix is identified with a unique Fix ID to help to distinguish each fix as it moves through the system. In the example below, the fix ID is CI-H-1. There is a title for the fix: Always Synchronize on a private final Field, and the category within which this fix belongs: Concurrency Issues.

There is also a description of the fix which includes the file name where the fix was produced: GossipSubjectImpl.java and optionally, depending upon the specific language being analyzed, the relevant method or class. In this example the method: registerObserver is called out. 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 link CWE-412 will take you to more information on the Common Weakness Enumeration (CWE) that is identified in this fix.

In the top right corner of the description 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. The results are presented in the order of higher severities first. Of course, you may choose to use the filter to affect what levels of severity you wish to see.

Severity
Category
CWE
OWASP
Directory
Severity