Security Hotspot findings on code that hasn't changed

I am using SonarQube version 8.6. We started to notice that there are Security Hotspot findings on code in git feature branches which have not been changed at all. Do security hotspot findings not adhere to the “new code” rule of the quality gate or is SonarQube mistakenly determining these files are “new code”? How can I determine how SonarQube is determining “new code” from analysis to analysis?

Hi Michael,

You didn’t elaborate on where you see the hotspots; if it’s in the Security Hotspots tab, you need to toggle the control near the top of the tab from Overall to New code in order to focus on the hotspots only in new code.

Look at the Measures tab of the branch and then drill into Size and then New Lines to see what SonarQube regards as the new code on the branch.

Lastly: 8.6 is several versions older than the latest release of SonarQube; please consider an upgrade to 8.9 when you can.

You didn’t elaborate on where you see the hotspots; if it’s in the Security Hotspots tab

Well, I selected the branch and I am on the “Overview” tab. On that tab is shows the status of the quality gate as Failed because the Security Hotspots findings have not been reviewed yet. If I then click on the failed condition (see screen snip) …

Screenshot 2021-06-09 133747
… it takes me to the Measures tab where it shows me 7 files which it considers New Code (see screen snip).

However, none of these 7 files have been changed for a long time (years in some cases). I have looked at the Git history of these files I can verify no commits to them recently. So I don’t know how/why SonarQube is considering these files as New Code.

Look at the Measures tab of the branch and then drill into Size and then New Lines to see what SonarQube regards as the new code on the branch.

This doesn’t tell me much because the “New Lines” value is 0 (see screen snip)

Screenshot 2021-06-09 134550

Some additional information I can give is the Security Hotspot counts for the branch activity (see screen snip).

On June 4th it went down from 51 to 42 then after June 4th it went back up to 51 again. This accounts for the 9 security hotspots the Quality Gate failure is telling me I need to review. But again, these 9 security hotspots to review are on the 7 files from the screen snip above and none of those files have changed recently. So I still don’t know how/why SonarQube is thinking they are New Code.

What get’s even more confusing, is that in the branch “Activity” tab, on June 4th it shows a quality gate failure, but subsequent activity does NOT show a quality gate failure in the “Activity” tab. This is confusing because on the “Overview” tab it shows a quality gate failure (see screen snip above) but not on the “Activity” tab.

Did you get any warnings on the recent analysis where the New Code was 0? And should there have been any new code (any actual changed files)?

I’m also curious if there were

  • variations on the state of the checked-out code between these analyses (are these based on pipeline runs that always use the same checkout mechanism or are there variations thrown in)
  • changes in the scope of what’s analyzed (changes to parameters like sonar.sources or sonar.exclusions)

I got a warning about file encoding on some of the files, but I looked at the logs and the files it complained about were not the same as the files it suddenly decided had New Code.

There should not have been any new code because this particular feature branch just deleted a few files. But what I find interesting is that the New Lines measure (see screenshot above) says 0, however, the Quality Gate fail status (see screenshot above) says “Security Hotspot Reviewed on New Code is less than 100%”. So how can the Quality Gate status be determining 7 JAVA files are “new code” but the “New Lines” measure is 0. So something seems disconnected.

There wasn’t any variation on the state of the checked-out code between analysis. It was just days between analysis and the code is always checked-out from scratch for every analysis.

There were not changes to sonar.sources or sonar.exclusions.