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…
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.
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?
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.
FYI: I started the same thread some time ago:
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
Hi,
was not changed in SonarJava 5.8. Is it still on the roadmap?
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 
@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,
It would be nice if this rule-references are added to the rule database, its always hard to find such “knowledge”.
A typical false positive looks like this:
final String LITERAL1 = "SELECT * from table1";
final String LITERAL2 = "SELECT * from table2";
...
String query = isBla()?LITERAL1:LITERAL2;
c.prepareStatteemnt(query)
Havent tested if the taint analysis also has a problem with it.
Hi @ecki,
Just to be sure I understand, you would like rule S2077 and S3649 to reference each other, explaining the difference between both rules. Is that it?
You mean rule S2077 currently raises on this code? If so I will move your answer to a separate thread so we can continue discussing it.
Cheers,
Yes, or more specifically in all cases where a rule is marked as deprecated or you know a better one to migrate to. I guess that seems most often be in the context of the commercial editions, so its also a form of advertisement. 
Yes, at least on Version 7.2.1 for Java, havent tried newer versions yet. Its welcome if you split the discussion off.