iCR for Python User Guides
iCR for Python 3.0.2
iCR for Python 3.0.2
  • Table of contents
    • Introduction
    • Overview
    • Getting Started
      • Installing iCR for Python
      • Managing your service
        • Opening Ports
      • Authorizing Access to Your Source Code
        • Authenticating GitHub Access with a Cloud-Based VCS Repository Service
          • Authenticating GitHub Access with a Private VCS Repository
        • Authenticating GitLab Access with a Cloud-Based VCS Repository
          • Authenticating GitLab Access with a Private VCS Repository
        • Authenticating Bitbucket Access with a Cloud-Based VCS Repository
          • Authenticating Bitbucket Access with a Private VCS Repository
          • Setting Bitbucket Server Credentials in the Navigator
    • Using the Navigator
      • Connecting to the Navigator
      • Setting your private passphrase
      • 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
        • Setting the scope of your analysis
      • 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 Directory pane
      • Filter by Category pane
      • 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
      • Capturing results for printing or sharing
      • Ending a reviewer session
    • When you are complete
    • Appendix – List of supported fixers
    • Appendix – Example Summary Report
    • Appendix - Sample Bug Listing
Powered by GitBook
On this page
  1. Table of contents
  2. Reviewing your results

Reviewer summary and filters

PreviousReviewing your resultsNextFilter by Directory pane

Last updated 1 year ago

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 Unresolved tab. It shows the total number of fixes (92 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 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:

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