Hello,
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?
Cheers
Ps. This rule is still enabled in Sonar way Built-in profile.
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.
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.
Well that explains everything 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.
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.
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.