We are facing a weird issue after the sonarqube upgrade to Enterprise Editionv10.8.1 (101195)[ACTIVE] . It is observed that, a recent Merge Request for one of the project started to show the vulnerabilities part of the rule " Hard-coded credentials are security-sensitive[csharpsquid:S2068]" as security hotspots. There was no code change on the files where the issues were reported. Whereas when we ran the master, these same vulnerabilities which were marked as “safe” long back, didnt re-appear as security hotspots to work on.
When we looked at the rules, " Hard-coded credentials are security-sensitive[csharpsquid:S2068]" this rule availability date shown as the recent date when the server was upgraded.
We want to know, why on master when we scan, it didnt throw these security hotspots, if it treats as safe there in master, then it should flow down the changes to merge request too. But, why in the merge request, it started to show security hotspots to workon.
Kindly clarify at the earliest as development teams are going crazy with the amount of re-work they need to do because of so many such rules…
On master - the code got scanned long time back (an year ago) and security hotspots related to rule “Hard-coded credentials are security-sensitive” were resolved as “Safe” on certain files.
There is no code change on these files since then.
Recently upgraded sonarqube enterprise edition to the latest. The rule “Hard-coded credentials are security-sensitive” started to appear as available from the date the sonarquber server is upgraded
There is a merge request to some other source file, obsolutely no changes to the source files where we closed security hotspots on master an year ago. But, this MR started to show the same security hotspots on those files though there are no code changes. Its like new security hotspots to work on. But there is no code change at all. We ideally think that this MR, should have synced the rationales from master and dont show these security hotspots.
Now scan, master, these security hotspots on same files are not open to work on.
Kindly elaborate the behaviour on point 4 and point5.
Again, Security Hotspots aren’t synched in PRs / MRs.
However,
If you’re seeing these Security Hotspots raised in an MR on unchanged code, then that implies a problem with the SCM data that’s available to analysis, and that problem probably shows up the analysis log.
And if so, and these Security Hotspots on untouched code still show up, then can you share your analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.