This is an archived version of the documentation for SonarQube-7.3.
See the Latest Documentation for current functionality.

Issue Lifecycle

Code Smell, Bug and Vulnerability Issue Lifecycle

Statuses

After creation, issues flow through a lifecycle, taking one of five possible statuses:

  • Open - set by SonarQube on new issues

  • Confirmed - set manually to indicate that the issue is valid

  • Resolved - set manually to indicate that the next analysis should Close the issue

  • Reopened - set automatically by SonarQube when a Resolved issue hasn't actually been corrected

  • Closed - set automatically by SonarQube for automatically created issues.

Resolutions

Closed issues will have one of two resolutions:

  • Fixed - set automatically when a subsequent analysis shows that the issue has been corrected

  • Removed - set automatically when either the related coding rule or the file is no longer available. The rule may not be available either because it has been removed from the profile or because the underlying plugin has been uninstalled. The file could be unavailable because it has been removed from the project, moved to a different location or renamed.

Resolved issues will have one of two resolutions:

  • False Positive - set manually

  • Won't Fix - set manually

Issue Workflow

images/download/attachments/11641181/IssueWorkflow.png

Issues are automatically closed (status: Closed) when:

  • an issue (of any status) has been properly fixed => Resolution: Fixed

  • an issue no longer exists because the related coding rule has been deactived or is no longer available (ie: plugin has been removed) => Resolution: Removed

Issues are automatically reopened (status: Reopened) when:

  • an issue that was manually Resolved as Fixed(but Resolution is not False positive) is shown by a subsequent analysis to still exist

Security Hotspot Issue Lifecycle

Security Hotspot issues have a dedicated lifecycle. They aren't considered actionable, and must be reviewed by a user with the "Administer Security Hotspots" permission.

Statuses

After creation, Security Hotspot issues flow through a dedicated lifecycle, taking one of four possible statuses:

  • Open - set by SonarQube on new issues

  • Resolved (Won't Fix) - set automatically by SonarQube when a Security Auditor Accepts the fix done by a developer on a Manual Vulnerability or when an Open Hotspot or Manual Vulnerability is Cleared by a Security Auditor.

  • To Review - set automatically when a developer requests a security auditor to Review the fix she has done on a Manual Vulnerability

  • Reopened - set when a developer Dismisses an Open Manual Vulnerability or when a Security Auditor manually reopens issues in order to run a new audit on already Resolved issues

Security Hotspot issues are only ever closed if the code containing the Security Hotspot is deleted. A Security Hotspot may also become Removed if the rule which identified the hotspot is removed from the project's Quality Profile.

Security Hotspot Workflow

images/download/attachments/11641181/HotspotWorkflow.png

Understanding which issues are "new"

To determine the creation date of an issue, an algorithm is executed during each analysis to determine if an issue is new or existed previously. This algorithm relies on line content hashes (excluding whitespace) the issue is reported on. For multi-line issues, we are using the hash of the first line. For each file (after detection of file renaming), the algorithm takes the list of base issues from the previous analysis, and tries to match with raw issues reported by the new analysis. The algorithm tries to first match using the strongest evidence, and then fallback to weaker heuristics.

  • if the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) > MATCH

  • detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH

  • on the same rule, with the same message and with the same line hash (but not necessarily with the same line) > MATCH

  • on the same rule, with the same message and with the same line number (but not necessarily with the same line hash) > MATCH

  • on the same rule and with the same line hash (but not the same message and not the same line) > MATCH

Unmatched "base" issues are closed as fixed.

Unmatched "raw" issues are new.

Purging Closed Issues

By default, Closed issues are kept for 30 days. For more details, browse the Housekeeping documentation.