"password" detected in names of constants

[gmpark...@gmail.com]

Almost all the vulnerabilities that are "blockers" detected in our software are because of a single rule, "Credentials should not be hard-coded".  We don't actually have any hard-coded credentials in the software.  We tend to use constants like :

private static final String PASSWORD_EXPIRY = "password-expiry";

Is there any way to stop this rule from generating so many false positives?

[Michael Gumowski]

Hello Greg,

Rule S2068 (that's the rule we are talking about, right?) has been reworked to somehow limit its noise in version 4.13 of SonarJava, and to make messages more explicit as well (SONARJAVA-2404). Could you please precise which version of the analyzer you are using? If  you are not using the latest version, it may worth giving it a try.

Now, regarding FP rate: because rule S2068 is a rule targeting vulnerabilities, its main interest is to raise issue everywhere a potential threat could be hidden. Consequently, we tend to allow rule to raise many issues, and sometime, with a high rate of FPs.

Everything here is based on the principle that each issue will have to be double check by dev teams, and (maybe in the vast majority of cases) subsequently discarded by closing it as "WON'T FIX"... 

From our point of view, identifying only one case which could have slept through is enough to make it valuable. Now, maybe the rule is simply not applicable in the context of your project(s), and a better approach could be to simply disable it.

On another subject, note that in this mailing list, we usually appreciate common greetings and other standard courtesies, especially when starting new threads. :)

Providing as much information as you can regarding your configuration and context is also useful (SQ version, analyzer version, rule key, etc...)

Cheers,

Michael

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/fe3d5e6e-10d6-43a6-93a6-5c852e9ec8c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
http://sonarsource.com

[Greg Parker]

Hello Michael,

Thanks for the quick response.  Yes it is indeed rule S2068 and we are currently running SonarJava version 4.14.0.11784.

I figured that this was the reasoning for it generating so many false positives.  I’ll just go through and discard these from the results.

Thanks 

[s53...@gmail.com]

Hi, I'm also using SonarJava version 4.14. and I get issues from this rule when there's "sandi" in the variabe name - I don't even have an idea what's the idea behind this.

Please cleanup this rule, we also have only false positives with this rule and only because of variable names that don't have anything to do with passwords or something similar.

Thanks,
Stefan.

[Tibor Blenessy]

Hello,

I think you will be happy to hear that we decided to make the list of detected patterns to be modifiable with rule parameter. Here is a ticket for the implementation SONARJAVA-2530 . 

Btw, "sandi" is password in Indonesian. 

Best regards

Tibor

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8586de2f-6809-4234-9d7e-b6d7d1aa528f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Tibor Blenessy | SonarSource

SonarJava Developer

https://sonarsource.com