What is SonarQube?
Definition and role
SonarQube is a static source code analysis solution focused on development quality. It is capable of detecting bugs, bad practices, vulnerabilities and maintainability issues (‘code smell’).
SonarQube brings together features that are designed to track down security flaws in source code.
Classed as an SAST (Static Application Security Testing) tool, it analyses the source code without executing it, identifying risks such as SQL injections or XSS (Cross-Site Scripting) attacks.
SonarQube helps developers to secure their applications right from the development phase, providing them with detailed reports and suggestions on how to resolve any problems or flaws identified.
SonarQube provides a centralised platform for monitoring both quality and security.
The anomalies detected are sorted by level of severity, and its web interface lets you assign them to developers, exchange comments or report false positives.
This management system encourages collaboration on security issues within teams, while also providing clear monitoring of the resolution of problems over time.
SonarQube reinforces prevention: by integrating it into projects during development, SonarQube helps to build more secure applications from the outset, by resolving vulnerabilities as and when they arise.
Comparison of the different types of application security tools
Application security testing tools fall into several categories, each using a different method of identifying vulnerabilities.
- SAST (Static Application Security Testing): These solutions, which include SonarQube, inspect the code without executing it.
They compare it to rules drawn up in order to identify known vulnerabilities. They may flag up a risk of buffer overflow, for instance, or the presence of secrets in the code.
Their great advantage? They can be integrated into the early stages of development, enabling problems to be corrected as the code takes shape.
They do have their limitations, though: focusing as they do on raw code, they miss out on problems linked to the configuration of the environment or actual usage.
Another drawback is that they sometimes flag up unnecessary alerts – false positives – that have no real impact on security.
SonarQube can identify risks in the code, but requires a human eye to sort alerts and does not detect flaws linked to execution or configuration.
- DAST (Dynamic Application Security Testing): Unlike an SAST, a DAST analyses an application while it is running, without having access to the source code.
Here, the tool plays a role that is similar to that of an attacker or hacker: it sends malicious requests to the application, to detect flaws.
Scanners such as OWASP ZAP or Burp Suite, for example, track down SQL injections, XSS, configuration errors or authentication weaknesses.
This method makes it possible to detect vulnerabilities that are only revealed at runtime.
On the other hand, it can only be used later in the lifecycle of an application, once it is in the testing phase, and the results thrown up often require more time and experience to interpret.
- IAST (Interactive Application Security Testing): IAST is a cross between SAST and DAST.
These tools, which are often software agents, are integrated into a part of the application while it is running – typically during the test phase – and scrutinise its behaviour from the inside, while analysing the targeted code.
In practical terms, an IAST agent monitors part of the application in real time (during automated tests, for example) and can link a problem to its exact origin in the code analysed.
The result: the ability to detect programming errors, as well as environmental or configuration problems, in a targeted part of the application.
This approach is less widespread, however.
In short, whilst SonarQube focuses on the code, a DAST analyses the behaviour of an application that’s running, and an IAST gets inside part of the application while it is running.
How does SonarQube analyse code security?
Main types of vulnerability detected
SonarQube identifies a large number of vulnerabilities in source code, based on security rules targeting the most common flaws.
SonarQube distinguishes between two categories: Vulnerabilities, serious flaws that need to be corrected as a matter of urgency, and Security Hotspots, sensitive areas that need to be reviewed manually.
Here are the main types of risk it detects:
- Injections (SQL, OS, LDAP, etc.): Sonar can detect invalid or unsanitised entries in the application that allow an attacker to execute arbitrary commands.
- Cross-Site Scripting (XSS): This reports cases where a web application returns uncontrolled injected content to the user, opening the door to stored or reflective XSS.
- Problems with authentication/authorisation: The tool identifies hard-coded passwords, obsolete authentication mechanisms or access controls that are too weak – although some cases require verification at runtime.
- Exposure of sensitive data: The software identifies cases where passwords have been stored in clear text, or a shaky encryption algorithm (such as MD5) has been used.
- Risky deserialization: It detects the deserialization of objects from dubious sources, which could potentially be exploited to execute malicious code.
- Vulnerable components: although this area (known as Software Composition Analysis) is not supported natively, SonarQube is able to flag up, by means of plugins for example, cases where risky libraries or frameworks have been used.
In short, SonarQube can detect most major vulnerabilities, reporting back on ‘issues’ with a description, a severity level (Blocking, Critical, etc.) and practical advice to guide the developer towards an appropriate patch.
Explanation of integrated security rules
SonarQube’s security rules are aligned with the major application security standards, providing a framework for evaluating and improving code. Here are the main standards referred to:
- OWASP Top 10: The Open Web Application Security Project is an international open-source community dedicated to improving the security of web applications.
It offers a ranking of the ten major web security risks, such as injections and flaws associated with identification and authentication.
SonarQube responds with rules tailored to suit each category.
Specific OWASP Top 10 reports show vulnerabilities by category (A1, A2, etc.), with a grade (A, B, C, etc.) reflecting the level of compliance.
This is a way of ensuring that the project complies with this standard.
- CWE Top 25: The Common Weakness Enumeration is a standardised catalogue of software weaknesses (bugs, design errors etc.) that can lead to exploitable vulnerabilities.
It lists common security weaknesses and its annual Top 25 highlights the most critical ones. SonarQube links its rules to these CWEs.
A dedicated report assesses compliance with this Top 25, facilitating technical discussions and the prioritising of major corrections.
SonarQube also incorporates recommendations from CERT Secure Coding and other standards into its approach.
Each rule often specifies its link with a repository, helping developers to grasp the importance of the flaw while raising awareness of best practice.
Static analysis vs. dynamic analysis
Static analysis (carried out by SonarQube) and dynamic analysis (using DAST or IAST tools) constitute two complementary pillars of application security.
Understanding the differences between them will help you get the most out of SonarQube, while placing it in the context of an overall security strategy.
- Static analysis: This involves examining the source code without executing it.
SonarQube does this by going through the code file by file and then applying rules to spot flaws in the code.
By way of example, user input that is injected into an SQL query without checking will be flagged as risky. The advantage is that you can act early, during the development phase, thanks to integration into an IDE (via SonarLint) or a CI pipeline, to check each commit.
Static analysis has its limitations, however. It cannot see errors linked to server configuration or complex scenarios that only emerge at runtime.
Some vulnerabilities require the context of execution in order to be identifiable.
- Dynamic analysis: Unlike static analysis, dynamic analysis enables the application to be tested while it is running.
A dynamic test involves performing a series of actions on an application (filling in forms, simulating attacks, etc.) and checking whether the application reacts in a way that reveals a security flaw or vulnerability (information leak, abnormal behaviour, etc.).
This approach makes it possible to detect vulnerabilities that are invisible in the raw code and only visible at runtime (authentication, session, configuration flaws, etc.).
The disadvantage is that this happens later in the development cycle, often during the integration phase, making corrections more difficult.
The other disadvantage is that it is up to the developer to diagnose the source of the vulnerability in the code.
SonarQube only performs static analysis. For complete security, you need to supplement your analysis with dynamic tests (automated DASTs, manual pentests).
The DevSecOps philosophy encourages the adoption of the ‘Shift Left’ approach, bringing in checks at an early stage while still carrying out verification (monitoring, production tests) at the end of the cycle.
In short, SonarQube and dynamic analysis complement each other: one secures the code, whilst the other tracks down flaws at runtime, thus covering the entire lifecycle of an application.
Configuring SonarQube
Installation and configuration
Installing SonarQube involves deploying a server (or using SonarCloud), creating a project, generating a token and using SonarScanner to analyse the code.
It can also be integrated with external databases and customised as required.
The steps to follow are:
- Installing the SonarQube server: Start by selecting the version that suits your needs. SonarQube is installed via a zip (Windows/Linux) or a Docker image.
By default, SonarQube includes a database that can be used for testing. For production use, we recommend connecting it to a database (PostgreSQL, Oracle, SQL Server).
Once launched, you access a web interface with dashboards on project quality and safety.
- Creating a project and generating a token: On the SonarQube interface, create a project that corresponds to the code to be analysed
The token will be used to launch scans from a CI pipeline or a local workstation, for instance.
- Code analysis with SonarScanner: SonarScanner analyses the code and sends the results to the server.
There are several types of scanner, for example Maven/Gradle for Java or for .NET.
You need to give it the server URL, the token and the project key. Other options are available for more specific needs (e.g. file or folder exclusions).
Once the scan is complete, the report appears in the SonarQube interface.
Installing SonarQube is a straightforward process on which plenty of documentation is available. SonarQube can be hosted internally or you can opt for SonarCloud, the SaaS version that makes maintenance of the tool more straightforward.
Personalising security rules and Quality Gates
Once SonarQube has been installed and set up, it is essential that you adapt it to suit your needs, so that it becomes a real security asset. The two main levers for this are: customising profiles (Quality Profiles) and configuring Quality Gates.
- Customise security rules (Quality Profile): SonarQube uses Quality Profiles to define which rules are applied during analysis.
By default, each language has a standard profile (‘Sonar way’), with a subset of generic rules.
However, when it comes to security, you’ll want to select the rules that are most relevant, depending on the context and the level of risk.
Profiles can therefore be specified by adding specific rules or by deactivating some of them, if they generate false positives, for instance.
The interface lets you sort the rules by theme or tag, and tick the ones you want to be activated. If required, you can even create your own rules, using plugins or third-party tools such as “Find Security Bugs” for Java.
- Configuring security-oriented Quality Gates: Quality Gates set quality thresholds for validating or rejecting a project.
The default Quality Gate requires that there be no new issues in a project, and also requires projects to comply with certain code duplication and test coverage thresholds.
To emphasise security, a Quality Gate can be customised so that it requires zero blocking or critical vulnerabilities on new code, and so that it requires all Hotspots to be examined.
The aim? To make security a blocking criterion: a critical flaw will cause the Quality Gate validation process to fail, preventing a production release in this condition.
It is good practice to implement this process gradually. New security flaws should be checked and limited first, for instance, before the scope is then extended to the rest of the application. This allows teams to make changes gradually and to remedy historical vulnerabilities little by little.
- Managing false positives and exceptions: Some alerts may be marked as ‘False Positive’ or ‘Won’t Fix’ if, after verification, they pose no real risk or the risks are accepted.
This should be used sparingly, but it does make the whole integration process smoother.
You can also use tags and the assignment of managers for clear, structured monitoring.
By customising the rules and Gates, you can adapt SonarQube to suit the specific demands of each project.
Automate analysis in a CI/CD pipeline
For better integration into processes, SonarQube can be integrated into CI/CD pipelines.
The aim is to automate code analysis in the pipelines. Here are a few examples of integration:
- Integration with GitLab CI: GitLab CI can be used to orchestrate analysis jobs.
Simply add a job to the ‘.gitlab-ci.yml’ file to launch the SonarScanner analysis.
This job will use the variables in the GitLab project to access the Sonar server (URL, token).
Example of how it can be configured:
"sonar_scan:
stage: analysis
image: sonarsource/sonar-scanner-cli:latest
script:
- sonar-scanner -Dsonar.projectKey=myproj -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=$SONAR_TOKEN
only:
- merge_requests
- main
"Result: each merge request or commit on the main branch triggers a scan.
GitLab can also stop the pipeline if the Quality Gate is not validated.
- Integration with Jenkins: Jenkins has a SonarQube plugin which makes it easier to run the scanner.
In Jenkins, you configure the Sonar server information (in the global config) and then in the pipeline (Jenkinsfile pipeline or freestyle job), you add a Sonar step.
Example of a declarative script:
"stage('SonarQube Analysis') {
steps {
withSonarQubeEnv('My Sonar') {
sh 'sonar-scanner -Dsonar.projectKey=myproj -Dsonar.sources=src/ -Dsonar.host.url=https://sonar.exemple.com -Dsonar.login=${SONAR_TOKEN}'
}
}
}"The Jenkins Sonar plugin also provides a waitForQualityGate step, so that the pipeline is stopped if the criteria are not met.
- Integration with GitHub Actions: On GitHub, you can either use the official ‘SonarSource/sonarcloud-github-action’ action (especially for SonarCloud), or summon the scanner directly from within a job.
Example of how the workflow might look:
"- name: SonarQube Scan
uses: sonarsource/sonarqube-scan-action@v1.2
with:
host_url: ${{ secrets.SONAR_HOST_URL }}
login: ${{ secrets.SONAR_TOKEN }}
projectBaseDir: "./"
" - Other CI/CD tools: SonarQube adapts to other systems such as Azure DevOps (with an extension), Bitbucket Pipelines, CircleCI, etc.
As part of a DevSecOps approach, the pipeline becomes a safeguard: production releases are blocked if security criteria are not met.
- IDE integration (SonarLint): For integration even earlier in the development cycle, you can use SonarLint in your IDE.
SonarLint is a plugin (available for IntelliJ, VS Code, Eclipse, etc.) that analyses code as it is being written.
It informs developers about flaws as they develop, enabling them to correct vulnerabilities before commits.
Since SonarQube is automated in the CI/CD, security is anchored at the heart of development.
Teams receive rapid feedback, make corrections and adopt security as an essential criterion for each delivery.
Best practice with SonarQube
Interpreting reports
Receiving security alerts via SonarQube is useful, but interpreting and responding to them is even more so.
The tool offers an overarching view and precise details, to make this task easier.
The dashboard shows a Security Score (A to E), the number of open Vulnerabilities and the Security Hotspots to check.
An E indicates that there are serious problems. This quick view gives an initial overview of the general state of the project.
In the Issues list, you can find the details you need to analyse and resolve the issue: title, severity, the rule broken and its location in the source code.
There is also an explanation of the risk and the solution. This advice is often accompanied by best practices or documentation.
The next step is to determine the action plan: correct critical vulnerabilities quickly, and make a plan for correcting minor ones, without allowing them to accumulate over time.
As far as the “Security Hotspots” are concerned, a review stage is essential: assign their verification to the team and then decide whether or not they should be corrected (false positive or accepted risk).
In short, using SonarQube Security properly means integrating these reports into the daily routine and overall management of projects.
Integrate the tool into a DevSecOps approach
For SonarQube to be at its most effective, it should be seen not as an isolated tool but as a building block in the DevSecOps culture. Here are a few tips:
- Opt for the ‘Shift Left’ approach: Integrate SonarQube into processes from the earliest stages of development. Making it a criterion for acceptance will lead to security being firmly rooted as a quality criterion.
- Raising team awareness: A developer who understands why a vulnerability is a problem will naturally code in a more secure way. SonarQube reports can help developers understand these risks and the solutions to them. Organising in-house training sessions can help reinforce this awareness. Over time, good practice becomes firmly established, with SonarQube acting as a safeguard.
- Integrate SonarQube into workflows: By automating analyses in CI/CD pipelines, integrating the results of reports into project management and managing vulnerabilities via tickets.
- Complement it with other tools: SonarQube focuses on static code analysis.
Ensuring complete, overall security also requires dependency analysis (e.g. Snyk), container scans (Trivy), dynamic analysis and manual testing, however.
To find out more about DevSecOps tools, we have a dedicated article.
Can SonarQube be integrated with a DAST or IAST tool?
Many teams look to combine different types of analysis in their CI/CD pipelines.
With SonarQube for SAST, adding a DAST (such as Checkmarx) or IAST tool can broaden the scope of analysis.
SonarQube does not, however, allow results to be grouped together in its interface.
Nonetheless, SonarQube can coexist with a DAST or IAST:
- Parallel execution in the IC: A dynamic analysis can also be launched in the pipeline. If one of the two methods detects a critical flaw, the pipeline can be blocked.
- Consolidation and centralisation of reports: For an overview, third-party tools such as ‘DefectDojo’ can import results from SonarQube and a DAST tool, providing a clear summary. Forges such as GitLab or GitHub also offer security dashboards.
- Synergy: SonarQube and DAST/IAST are not opposites, they complement each other. Both are essential. Combining them enhances vulnerability detection.
In short, combining SonarQube with dynamic analysis tools extends security coverage. Coordination is achieved through the processes – pipeline, unified reports – rather than through SonarQube alone.
Limitations and alternatives to SonarQube
Limitations of SonarQube in terms of application security
SonarQube is limited to static code, and therefore misses vulnerabilities that only appear at runtime.
Its analysis is based on rules defined by Sonar. New vulnerabilities may go undetected and false positives may be generated.
SonarQube only scans code. It does not detect problems with infrastructure or server configuration. It may produce false positives and is not a substitute for an infrastructure security tool.
Comparison with other security tools
Various tools meet needs similar to those covered by SonarQube, each with its own specific features:
- Checkmarx: This solution offers more features than SonarQube. The platform integrates SAST, DAST, SCA, container security and IaC.
- Veracode: Veracode offers SAST, DAST and dependency analysis. You send it your code and it sends you a detailed vulnerability report, ideal for compliance and audits.
- Snyk: Snyk is a versatile tool, offering SAST, SCA, container and IaC security.
How does Qim info help you implement SonarQube?
At Qim info, we work with you every step of the way to integrate SonarQube Security and turn application security into a driver of performance. Thanks to our personalised approach, we can train you in security issues, how to get to grips with the tool and how to integrate it seamlessly into your CI/CD pipelines. We also provide regular follow-up, to help you decipher reports, adjust rules and connect SonarQube to other security solutions.
We offer three types of support:
- Consulting and training: analysis of your needs and practical training on the tool.
- Technical implementation: deployment of the server or SonarCloud, configuration of profiles and Quality Gates, integration into your CI/CD pipelines.
- Monitoring and progress: assistance with report analysis, ongoing adjustments, and synergies with other security tools, including container image scanners.
Drawing on our expertise in DevSecOps and security, we can help you embed SonarQube in your practices over the long term. The result: teams that are more autonomous, code that is more robust and projects that are better protected.
The teams at our Centre of Expertise have a shared knowledge base. They benefit from cross-fertilisation of skills, ensuring they can keep pace with all the latest developments. Opt for collective excellence, to secure, optimise and develop your IT environment with confidence.
