Differing Security Vulnerabilities detected after upgrading to CE 7.9.1

SonarQube
1

I have recently upgraded from SonarQube CE 7.6 to Version CE 7.9.1 and also updated SonarScanner from version 2 to version 3.

I notice on exactly the same (source code) build and scan that some of the Security Vulnerabilities are no longer reported as Security Vulnerabilities, but instead are logged in the Security Hotspots.

I am referring to issues that were deemed as a Blocker and Critical Security Vulnerabilities (in 7.6) are now not flagged as such (in 7.9.1) but are reported as a Security Hotspot.

I was wondering if anyone else had experienced this before and could shed some light on different results. thanks

3

Hi @nigelbrown,

Could you give us more detail on those rules? Their name or key would help.

We have changed the type of a few rules from Vulnerability to Security Hotspots since the concept of Security Hotspots has been added. We did this when the rule was actually pointing to security sensitive code which required a code review. We kept only vulnerability rules which have a high chance of being an actual vulnerability without needing a code review.

Cheers,
Nicolas

5

Hi @Nicolas_Harraudeau, thanks for the reply… here are some specific examples. They seem to be mainly around JavaScript as far as I can see.

Shown as Critical Vulnerabilities in Version 7.6 but not in Version 7.9.1
(JavaScript) Review the arguments of this “eval” call to make sure they are validated
(Dynamically executing code is security-sensitive) javascript:Eval

(JavaScript) Review this “Function” call and make sure its arguments are properly validated.
(Function constructors should not be used) javascript:S3523

regards
Nigel

6

Thanks. javascript:Eval, i.e. “Dynamically executing code is security-sensitive” has changed in the following way:

  • It has become more generic. It now matches both “eval” and “Function” construction.
  • It has become a Security Hotspot because not every call to “eval” or “Function” is vulnerable. They might be executed on a hardcoded string, which is safe enough. The rule removes the most obvious cases but it will not follow function calls.

Rule javascript:S3523 is now deprecated in favor of javascript:Eval.

javascript:Eval might change again in the future as we plan to detect injection vulnerabilities in javascript. When this happens we will be able to tell exactly where the code is vulnerable with very few false positives. We already did this for java, C# and PHP, here is an example. When this happens we deprecate the Hotspot rule and create a dedicated Vulnerability rule.

1 Like