S2077 has been deprecated but documentation doesn't include a justification


(Adam Gabryś) #1

I’m confused why S2077 rule has been deprecated. There is no justification in the rule documentation. I’ve found the commit which marked the rule as deprecated, but commit message doesn’t help:

Rule metadata update

Could you explain me the reason?


Ps. This rule is still enabled in Sonar way Built-in profile.

Deprecated rule squid:S2077 still on Sonar way and causing false positives
(Michael Hill) #3

I’m curious about this too. Any ideas anybody?

We are running SonarQube 6.7.5.

(G Ann Campbell) #4

Hi guys,

The deprecation message says to use S3649 instead.

In general, when we deprecate one rule in favor of another it’s because we believe the replacing rule to be better in some or all regards. In this case, we’ve deprecated a simple heuristic rule in favor of a new taint analysis one.


(Michael Hill) #6

Thanks @ganncamp, that helps clear things up.

It looks like this was a more recent doc update which might explain why we’re not seeing this in our SonarQube instances.

I don’t see the S3649 rule in SonarJava yet either (5.6 build 15032, which seems to be the latest available on SonarQube LTS), but I suppose we might just need to wait for an update to come out for that.


(G Ann Campbell) #7

Hi Mike,

That’s the part I was hoping you wouldn’t tell me. :grimacing:

In fact, the taint analysis rules are only available starting with the Developer Edition($).


(Michael Hill) #9

Well that explains everything :laughing: I’m actually in the process of upgrading our instance from 5.6.4, so I’ll keep this in mind as we consider the paid on-prem solutions, too.

Thanks for the help.


(Nicolas Harraudeau) #12

Hi @agabrys, @mike12489,

Thank you again for your feedback.

I just wanted to let you know that since SonarJava 5.9 the deprecation on rule S2077 has been removed and it is now a Security Hotspot rule. As explained in the documentation, 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.

As mentioned by @ganncamp , the new rule S3649 is different in that it is better at finding real vulnerabilities. It uses a 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.

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


Clarification on squid:S2077 evolution
(Hilal Emeksiz) #13

Hi Nicolas
SonarQube Version 7.0 and we still not see 2077 in Sonar Way profile is it because of our sonarqube version?

Thank you

(Nicolas Harraudeau) #14

Hi @Hilal_Emeksiz,

The change mentioned above was made in SonarJava 5.9, which is only compatible with SonarQube 6.7 and SonarQube 7.3+. The reason is that Security Hotspots are only available since SonarQube 7.3.

So yes, the problem you encounter comes from the SonarQube and SonarJava versions.

As a side-note for people reading this message later, in SonarQube 6.7 the rule is not part of “Sonar Way” either as it is typed as Vulnerability instead of Security Hotspot. This was done for backward compatibility.