[sonarCloud] - Security Hotspots accepted as safe are flagged again in the next analysis

SonarQube Cloud
1
  • ALM used - GitHub
  • CI system used - GH Actions
  • Scanner command used when applicable (private details masked)
  • Languages of the repository - Typescript
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting) - n/a

Steps to reproduce

  • Our sonarCloud scan is detecting Security Hotspots on our repository main branch (example: possible hardcoded credentials).
  • The suspected vulnerabilities have been reviewed and part of them has been flagged as safe (test data fake credentials not exposing any sensible information).
  • At the next scan run on the main branch, suspected vulnerabilities already flagged as safe are back again as security hotspot detected to be reviewed.

Could you please help me to understand what I am overlooking?
Many thanks in advance

6

Hello Elisa,

Is your main branch correctly detected as a long-lived branch ? (just like in the example screenshot below)

Screenshot 2023-09-20 at 10.26.49
Screenshot 2023-09-20 at 10.26.493452×1150 234 KB

7

Hello Quentin,
yes it looks to be correctly set as long lived branch

image
image2780×518 32.2 KB

8

Hello Elisa,

Sorry for the delay, I’m having a look at it today and will update you.

9

Hello @ElisaDellaC

Here are a few thing to check/try to help you find the issue :

  • Can you try to edit a file like a project readme or a single file that has nothing to do with the security hotspot to see if the security hotspot comes back as well in this case? Editing the code involved in a security hotspot makes the hotspot appear again, because it’s now a different code.

  • Verify that in your pipeline, when you checkout your code from git, you do it with full history. No history means everything is considered new code everytime

  • After that, if the issue still happen, you can send me (through private messages) the Analysis id of the last analysis that reopened security hotspot so I can have a look.

Best,

10

Hello @quentin.chevrin,
thank you so much.

  1. Editing a single file do not makes the security hotspot come back
  2. We were just checking out the last x commits, so there might be indeed the misconfiguration that is causing the issue.

Adjusting the pipeline to fetch full history, running some further tests and I’ll come back to you. Thanks a lot for your help

2 Likes
12

Hey @quentin.chevrin,
I’m back with some questions.
Checking out the entire history worked fine for us for a while.
We are back experiencing problems since Nov 28th where a lot of security hotspots that were already marked as safe were back again on the master branch.

I see that coincidentally changes in the rules have been deployed on the same date.
What does it happen when rules or the logic behind them are modified and a new version is deployed? Are accepted vulnerabilities discarded since the new logic might detect things differently?

If the above is true, is there any way in which we can limit the impact of future updates?

Thanks a lot for your help

14

Hello @ElisaDellaC

Changes in the rule should not reopen security hotspots marked as safe.
So you don’t need to worry about having to close all your security hotspots every time we update our scanners.

What can happen is: if an analysis marks a security hotspot as resolved (which closes the hotspot) and then a later analysis finds this security hotspot back, then the security hotspot is raised again to you for action.
Sometimes, when you have issues on your CI, you can run an analysis with no files, or very few files and it will close all hotspots, and then a later normal analysis will re-open everything.
We have an improvement for this on our radar but I don’t know when it will be released.