Page History

SonarQube (SQ) is an analysis tool aimed at performing automated code reviews based on static code analysis, and supporting expert reviewers in manual reviews. The WP9 T2 team maintains an instance of SQ available at https://sonarqube.software.geant.org and offers software development teams in GÉANT a variety of services based on SonarQube capabilities. In the cover folder Software Reviews we describe the types of reviews offered by the WP9 T2 team.

...

More detailed information is provided by the Issues screen. It presents the list of all issues discovered by SQ, either in the past or currently. On the left-hand side, there are various filters that help in managing the scope of presented issues. Filtering options include the type of issue, its severity, resolution, current status and other information. Please note that the filters are cumulative, i.e., they produce a conjunction of all imposed filters.

SQ capabilities supporting cross-validation

SQ has a number of built-in capabilities that support performing the manual cross-validation of the issues identified and collected by SQ. For each identified issues ('Issues' tab), the reviewer may:

• adjust the type of the issue ('Code Smell', 'Vulnerability', 'Bug' - although it is not recommended to alter this value)
• update the severity/priority of the issue ('Info', 'Minor', 'Major', 'Critical', 'Blocker')
• update the status of the issue ('Confirm', 'Resolve as fixed', 'Resolve as false positive', 'Resolve as won't fix')
• add a comment
• add a label/tag

SQ allows for bulk changes to multiple issues (e.g. adding the same tag to multiple issues in one go).

In addition, SQ reports an estimated remediation effort, showing the time required to adequately address and fix the issue. 

Outline of the proposed procedure

By clicking on an issue, a reviewer can get a contextual description that includes the affected code snippet, with marked subject areas and recommendation provided by SQ rule that identified the issue. For example, code duplications may span across several locations in the code; SQ identifies and marks each of them, so that it is easier to spot them and evaluate their actual impact on the affected quality characteristic.

For each issue reported by SQ (please note that the current view of the issues can be adjusted using filters), the reviewer:

1. analyzes the issue by inspecting the code in SQ; SQ highlights the code affected by the issue
2. adjusts the type of the issue (only if it is definitely required!)
3. updates the priority of the issue (only if it is definitely required!; the reviewer should be particularly cautious when lowering the priority)
4. validates the status of the issue by setting
   
   1. 'Confirm', if the issue has been correctly classified by SQ
   2. 'Resolve as fixed', if the issue has been already fixed in the code since the analysis was performed; SQ will close the issue on the next iteration of analysis
   3. 'Resolve as false positive', if the context of the issue indicates that it is invalid, although technically it conforms to the definition of the issue of a given type
   4. 'Resolve as won't fix', if the issue is valid, but does not require fixing (e.g., accepted technical debt)
5. optionally adds a comment with further details for this issue

Upon the next analysis, issues marked as 'Resolve as fixed' will be inspected by SQ again. If the issue is indeed no longer present, SQ will mark the issue as Closed; otherwise, the issue will be Reopened.

Please note that issues marked as 'Resolved' can be reopened by the expert at a later stage. Moreover, other attributes (such as tags) of Resolved issues cannot be updated; the issue needs to be reopened to be further edited.

The person assigned to the issue should not be altered by the reviewer.

Security Hotspots screen

The Security Hotspots screen reports... (TODO: Stefan)

...