Security-related rules
The SonarQube Cloud Quality Model has different types of rules: reliability, maintainability, and security (issues and hotspots) rules. There are a lot of expectations about security, so below we explain some key concepts and how the security rules differ from others.
What to expect from security-related rules
As with other types of rules, we try to ensure that no false positives are raised: you should be confident that anything reported to you as an issue is really an issue.
Under the hood, SonarQube Cloud uses a variety of source code representations and detection techniques to reliably find all the different types of security issues that can arise.
- Security-injection rules: there is a vulnerability here when the inputs handled by your application are controlled by a user (potentially an attacker) and not validated or sanitized. When this occurs, the flow from sources (user-controlled inputs) to sinks (sensitive functions) will be presented. To do this, SonarQube Cloud uses well-known taint analysis technology on source code which allows, for example, the detection of:
- Security-configuration rules: here there is a security issue because the wrong parameter (for example, invalid cryptographic algorithm or TLS version) was set when calling a sensitive function or when a check (for example, check_permissions() kind of function) was not carried out, or was not in the correct order. This problem is likely to appear often when the program is executed (no injected/complex attacks are required, unlike in the previous category):
These security issues are then divided into two categories: vulnerabilities and hotspots (see the main differences on the Security hotspots page).
Security hotspots represent code locations that should be reviewed, but are not necessarily real vulnerabilities.
For example, most injection rules are vulnerabilities: If a SQL injection is found, it is certain that a fix (input validation) is required, so this is a vulnerability.
On the other hand, the lack of an httpOnly flag when creating a cookie is something that could be a problem, but might not be. As it is not always possible to implement the httpOnly flag, determining the true level of danger requires review by a developer. Therefore, this is a hotspot.
With hotspots, we want to help developers understand information security risks, threats, impacts, root causes of security issues, and the choice of relevant software protections. In short, we really want to educate developers and help them develop secure, ethical, and privacy-friendly applications.
Which security-standards are covered?
Our security rules are classified according to well-established security-standards such as:
The standards to which a rule relates will be listed in the See section at the bottom of the rule description. More generally, you can search for a rule on rules.sonarsource.com:
- Java-vulnerability-issue-type: all vulnerability rules for Java language.
- Java-hotspots-issue-type: all security-hotspot rules for Java language.
- Java-tag-injection: all security-injection rules for Java language.
Was this page helpful?
© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.
