Sonarcloud raising issues in codebase a long time after merge

SonarQube Cloud
1
  • ALM used - GitLab
  • CI system used - GitLab

We run a Sonarcloud scan in CI both as part of our merge request pipelines and also on the main branch of our repository.

Currently the Sonarcloud scan is failing on the main branch of our repository.

image
image1542×901 88.5 KB

One of the issues which is failing the sonar quality gate starting 24th July is a vulnerability in a file.

As our quality gate requires there to be no vulnerabilities this means the scan on main pipeline CI is failing.

However, looking in GitLab I can see that the file containing this vulnerability was last merged into main branch on 26th June and in this merge pipeline no issues were found.

image
image1270×264 23.9 KB

Does anyone know why this issue is not being found in the Sonarcloud scan merge request pipeline or for subsequent Sonarcloud scans in pipelines ran on main branch but is appearing so long after the change to the file was merged into main branch? Is it related to the change in version of the codebase?

2

Hey there.

What programming language is the vulnerability raised on, and what is the specific vulnerability?

3

the programming language is java and the vulnerability was “disable access to external entities in xml parsing”

however this is just one example there are other issues that have arisen in other java files that have not recently changed and passed on the Merge Request pipeline and did not fail on subsequent main pipelines.

4

hi,

Is there an update on this issue?

We are still seeing the same problem when we create new releases.

5

Any update here? We are still seeing this on sonarcloud.
We mark vulns as safe on main but then when we cut a release branch they are all re-opened and fail our pipeline then requiring duplicate manual work to mark them as safe again.
This also happens with issues and the blockers also need to be reviewed to get our quality gate to pass.

6

Hey there.

Sorry that this thread got lost in the shuffle.

A few thoughts:

Analysis gets smarter over time (as we fix false-positives or introduce new rules), so if you have a Quality Gate that requires 0 vulnerabilities on Overall Code… then naturally the Quality Gate will start failing. If the Quality Gate is failing immediately after merging the pull request, that’s a different story.

On the first analysis of a long-lived branch, issue synchronization should make sure that all vulnerabilities marked as “false-positive” or “won’t fix” are synced.

FYI, there’s no “safe” status for vulnerabilities – can you clarify if you mean security hotspots (and if so, if only security hotspots are affected by issues losing their status?)

7

Hi Colin,

Thanks for the reply.

  • Is main your main branch on SonarCloud?
  • Are these long-lived branches or short-lived branches?

Yes, main is our main branch in sonarcloud and these release branches are long-lived branches.

Yes, it is the security hotspots that we are marking as safe and then that reappear.

8

These release branches are short lived for each release, but as soon as we create them they seem to get a different failing sonar vs our usual short-lived branches. Ah, we’ve marked them as long lived in sonar, so I presume this is the issue? We will change this and get back to you.

Thanks.