Security Should Not Be an Afterthought for Code Quality Checkers

Security should never be an afterthought!   

Application security testing has been around for a long time, but few development teams are genuinely interested in testing their code for vulnerabilities. Security is still very much the concern of security specialists and the CISO. While progressively higher stakes are forcing development teams to “do something” about application security, they often take the path of least effort.  

Recently, I was asked to evaluate SonarQube as a security testing tool. Due to its widespread use as a code quality checker, development teams perceive it as an easy and cost-effective way to implement security testing procedures to make their apps more secure.  

My first impression of SonarQube was extremely positive. Easy navigation, clear views and contextually relevant information made it obvious why development teams love it. However, as a security researcher, I was disappointed with its security-related features. 

While the application security testing landscape is littered with solutions, the primary benchmark for preferring one solution over another is the accuracy of its findings. I expect these tools to indicate precisely where vulnerabilities exist, point me to the cause of each, and provide fix recommendations that are clear and easy to implement in my code. And it goes without saying, they should avoid false positives.   

SonarQube, however, seems to only enumerate the locations of possible (not actual) issues and offers only general advice as to what should be done to avoid such issues.   

It’s a ‘good practices’ checklist and not a security testing tool.  

To be fair, SonarQube is quite open about the limitations of their security testing tool (https://docs.sonarqube.org/latest/user-guide/security-rules/) and through their documentation, cautions users from expecting the same level of accuracy found in their code quality analysis.   

SonarQube’s security analysis reports distinguish between “vulnerabilities” and “hotspots.” According to the documentation, vulnerabilities are actual issues that require immediate action. SonarQube provides issue descriptions and code highlights that explain why your code is at risk. But as a security expert, I can say that the vulnerabilities identified in the two apps I used for testing, Damn Vulnerable Web App (DVWA) and WebGoatPHP, were not actual vulnerabilities in the sense that they were not exploitable by an attacker. Furthermore, SonarQube clearly failed to uncover vulnerabilities that were deliberately planted in these apps.   

Furthermore, the hotspots pointed out by SonarQube were locations where vulnerabilities commonly occur, such as queries to a database. Every hotspot is accompanied by high-level explanations for how the code section often gets exploited and what should be done to mitigate the (possible) vulnerability. Once you’ve gone through the hotspots and added suitable mitigations to your code, it is impossible to tell whether proper protection exists. While you could, in theory, review the hotspots one by one, that’s a lot of code to review every time a change is introduced.  

In summary, SonarQube provides useful facilities for security code review. If you’re just getting started, it will help you perform an exhaustive examination of your code and help you to manually validate security protection has been applied in all the relevant location.  

But, once you’ve done that, do yourself a favor and get a dedicated security testing and analysis tool. These tools find the high-severity vulnerabilities that attackers can actually exploit, and provide actionable fix recommendations that will pinpoint the problem and the corrective action(s) needed.