Sonarlint intellij : "secrets:" played and reported in sonarqube connected mode

Hello,

(notice : i created an account on https://jira.sonarsource.com, but i dont have the rights to open a ticket, dunno why, so i post here).

  • versions used

intellij : IntelliJ IDEA 2020.3.3 (Community Edition)
Build #IC-203.7717.56, built on March 15, 2021
Runtime version: 11.0.10+8-b1145.96 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 4.19.0-16-amd64
GC: ParNew, ConcurrentMarkSweep
Memory: 4012M
Cores: 12
Non-Bundled Plugins: com.eugenePetrenko.idea.dependencies, Error-prone plugin, zielu.gittoolbox, GrepConsole, org.sonarlint.idea, com.thoughtworks.gauge, org.jetbrains.kotlin, JProfiler
Current Desktop: XFCE

sonarqube : 8.7.0.41497

sonarlint : 6.0.0.37696 (intellij plugin)

  • error observed

Connected to a sonarqube server, some rules, “secrets:” related are emitted.
These rules do not exist sonarqube server end (they were not reported before sonarlint plugin upgrade, mvn sonar:sonar do not report them).
Since we are working on sonarqube connected mode, i assume they must not be reported sonarlint + intellj end, but they are.

I tried unchecking all rules into the new settings tab “Tools>SonarLint>Rules tab” : no effect.
I tried Intellij invalidate cache & restart : no effect.

I assume these “local” rules sonarlint end are played even if connected to sonarqube : it sounds like a bug to me.

  • steps to reproduce

Launch full sonarlint analysis, sonarqube connected mode, on a project which have zero sonarqube warnings : some “secrets:” warnings are emitted, these “secrets:” rules do not exist sonarqube server end, they should not be emitted.

  • potential workaround

I found no workaround at this stage. Before sonarlint plugin upgrade, this was not occuring.

Hello @Champax.

Thank you for you valuable feedback on this feature and welcome to the community.
We aware of this behaviour and do not consider it’s a bug. Secrets being analysed only on SonarLint side. And, when connected, SonarLint ignores local settings and applying SonarQube or SonarCloud Quality Profile. Since secrets are not supported by SonarQube and SonarCloud (rational behind that is that’s better to spot them before push, not after, so IDE is the place you want to find such issue) - there is no way to disable them on server.
It’s possible to change this behaviour and let user to disable secrets rules when connected, but we are really curious to know what is the reason. Can you elaborate more about your desire to disable secret rule(s)? Are you getting false positive? Or you getting true positive but do not want to get them reported? If so - what is the reason?
Note: I moved this post to feature request category.

Hello,

Thank you for the feedback!

The reason is simple : when connected to sonarqube, i expect no warnings at all (we break merge requests & builds in case of quality gate failings - 0 warning allowed, sonarqube based)

I expect sonarlint - connected to sonarqube - to emit the same warnings as our build systems, so developer can, inside intellj, fully validate that everything is ok.

Having sonarlint - connected to sonarqube - emitting warnings by its own is weird : developer think the merge & build will fail, so they may try to fix them, but these warnings are not sonarqube initiated, so these fixes are not necessary at this stage.

So, in connected mode, i would like this disabled.

Moreover, as specified into the “Rules” tab, i quote : “Note : When a project is bound to sonarqube, only rule configurations from server apply”. It seems it is not the case.

Hope this clear, if not, ping me.

Hello @Champax ,
thanks for the explanations you provided, it is clearer now.

Let me add that the current situation is temporary, as we envisage to add the secrets detection in SonarQube as well in the future.
Although we don’t have an ETA yet, when the feature will be added to SonarQube, you’ll be able to configure the rule for secrets detection in your quality profile, and those issues will only be raised in SonarLint if they are activated in the quality profile.

We decided to first ship the “Secrets detection” feature in SonarLint because this is where we think it will bring the most value to our users, as this way they can prevent those secrets to leak in the first place, instead of undergoing remediation actions once the secrets have leaked. We feel it is critical to avoid secrets to leak into repositories (after all, is there any good reason to allow secrets to leak into a repository?), and I invite your to read our motivations in our blog post: Launching ‘Secret Detection’ to keep your Cloud ‘Secrets’ safe

I’d be curious to know whether, beyond the need you expressed for SonarLint to emit the same warnings as your build systems (which is totally clear to me and makes sense), do you have any feedback about the issues that were emitted by SonarLint in your case?

  • are they real secrets or do you consider them as false positives?
  • if they are false positives, is it possible to share some example with us?
  • if they are real secrets, do you feel that the need “avoid SonarLint to emit warnings that are not configured in your build systems” is a stronger one for you than “avoid secrets like token and authentication credentials to leak into repositories”?

Moreover, as specified into the “Rules” tab, i quote : “Note : When a project is bound to sonarqube, only rule configurations from server apply”.

I agree, the label is not accurate, we’ll improve this description in the next version - thanks for pointing that out.

To sum up, until the feature will be added to SonarQube, today secrets detections are always raised as issues in SonarLint when your project is bound to SonarQube. When we implemented the feature, we felt this is acceptable as it brings a real value to developers, and that avoid leaking secrets is critical.
I am happy to hear your thoughts on this; although we do not plan to change this in the immediate, we’ll certainly revaluate if we see a consensus among users (including further reaction and upvotes in this thread) that the current behavior causes too much frustration.