Deprecated rule squid:S2077 still on Sonar way and causing false positives

java
sonarcloud
rules

(Roy Sela) #1

We’re using SonarCloud and from reason I can’t understand the default profile (Sonar way) still holds squid:S2077 activated although it’s deprecated and actually detecting false positives (not always but on various occasions).

I can give a false positive example but since its already deprecated I believe the right thing to do it to remove it from SonarWay…

Note this is an OWASP-A1 & SANS top 25 vulnerability rule so the implications are severe from status perspective…

image


(Nicolas Peru) #4

Hi, indeed you are right, the rule should be removed from Sonar way and will be in the next release of SonarJava (5.8) which is not scheduled right now.


(Roy Sela) #5

Ok, is there an ETA? will it be released in the next month or so?

Meanwhile what could be the best workaround? I can create a custom quality profile based on the Sonar way and deactivate this rule, but then what will happen when the next release of the Java agent will be published? Will my profile be updated with the new rule changes, or will I need to somehow know about the new release and update my profile (or revert back to the Sonar way) in order to get those new rules?


(Nicolas Peru) #6

There is no official ETA but SonarJava is generally released about once a month.

Meanwhile you can create a custom QP that inherits from sonar way and exclude the rule but in this case I would suggest to live with it and wait for the next update of SonarJava on sonarcloud.


(Adam Gabryś) #7

FYI: I started the same thread some time ago:


(Jörg Sesterhenn) #8

I created a custom QP to deactivate said rule. Sonarqube states this is not possible since the rule is inherited!

Could you please provide this capability? We intend to use inheritance to do just this in the future (customize the sonar way without loosing updates).

TIA
Jörg


(Robert Paasche) #9

Hi,

was not changed in SonarJava 5.8. Is it still on the roadmap?


(Nicolas Harraudeau) #11

Hi @Roy_Sela , @agabrys, @Joerg.Sesterhenn,

Thank you for your patience. As of SonarJava 5.9, which was released two weeks ago, rule S2077’s type changed from “Vulnerability” to “Security Hotspot”. The deprecation has been removed.

Security Hotspot rules raise issues on security-sensitive code which needs to be reviewed. The goal of these rules is not to pinpoint real vulnerabilities, but instead to guide security auditors during their code review, thus simplifying their work. Security Hotspot issues do not count in the Quality Gate.

The rule S3649 replaces S2077 as “Vulnerability rule”. It uses SonarQube’s taint analysis engine which creates less false positives and explains where the injection comes from. However, just as any other taint analysis engine, it cannot detect every possible injection. Only a “manual secure code review” (see OWASP doc) can do it, which is why we added the concept of Security Hotspots.

The taint analysis engine is available starting with the Developer Edition. Security Hotspot rules are available in the SonarQube Community Edition and can be accessed via the Security Report. This is a new feature and we welcome all feedbacks :wink:

@Joerg.Sesterhenn Regarding your request to disable inherited rules, this is a separate discussion. May I ask you to create a new thread in https://community.sonarsource.com/c/suggestions/features?

Cheers,