Editor's Note: This post now contains outdated information. Detection of security vulnerabilities is available since SonarQube Server 7.2. Find more information on SonarQube Server here.
TL;DR overview
- SonarQube identifies security vulnerabilities in source code through static application security testing (SAST), detecting issues including SQL injection, XSS, buffer overflows, and hardcoded secrets before code reaches production.
- Taint analysis tracks untrusted data flows across files and functions to detect complex injection vulnerabilities that simple pattern matching cannot find.
- SonarQube integrates vulnerability detection directly into the developer workflow—from real-time feedback in the IDE to automated pull request analysis and CI/CD quality gates—so security is addressed at the point of code creation.
- The platform covers 35+ programming languages and frameworks and maps findings to standards including OWASP Top 10, CWE Top 25, and PCI DSS for compliance reporting.
During the last few months, Sonar has definitely become the leading Open Source Platform to manage Java code quality. The objective to democratize access to code quality is becoming concrete.
However when analyzing source code, quality is only one aspect of things. The ultimate platform should be able to handle Quality, Security and Architecture. Sonar 2.0 will take care of Architecture with a DSM and several valuable Object Oriented metrics.
What is the plan to handle Security ? Technically speaking, there is no difference between a quality rule and a security rule. They both consist in writing a piece of code that analyzes an Abstract Syntax Tree (AST) or the bytecode depending on what needs to be done.
Sonar already embarks a bunch of security rules that detect security vulnerabilities. What is really missing today in Sonar is the possibility to group rules by security categories. This will be implemented at some point in time with tags associated to each rule. For now and for people concerned by Security, there are two solutions to detect security breaks. First is to use the Security Rules Plugin that highlights files with such breaks. The second one is to look directly at available security rules :
SQL Injection Vulnerability
Read this very well-written page on the OWASP web site, to quickly understand why you should activate the two following Findbugs rules :
- Nonconstant string passed to execute method on an SQL statement
- A prepared statement is generated from a nonconstant String
Password Management Vulnerability
Those two other Findbugs rules will create respect for the person who someday invented the word "password"
- Hardcoded constant database password
- Empty database password
Error Handling and Logging flaws
When there is an airplane crash, the black box is the only way to perfectly understand what happened to be able fix the root cause. A software has its own black box, and the following PMD rules will make it effective :
- Preserve Stack Trace.
- Avoid Catching Throwable
- Exception As Flow Control
- Avoid Throwing Null Pointer Exception
- Avoid Print Stack Trace
- Avoid Using System Println
Insecure direct object reference
Do you feel confident to give the keys of your car to somebody you don't know ? To avoid this, here are the Findbugs/PMD rules that should get activated :
- May expose internal representation by returning reference to mutable object
- May expose internal representation by incorporating reference to mutable object
- May expose internal static state by storing a mutable object into a static field
- Public static method may expose internal representation by returning array
And some more...
- Do Not Call System Exit
- Servlet reflected cross site scripting vulnerability
- ...
Those available rules are a good start to identify security vulnerabilities. If you want to increase the set of existing rule to help Sonar grow on the subject, please create Jira tickets on the "Security rule" component to request for new rules.