DevSecOps-2: Integrating and Running SonarQube into Azure Pipelines, and Examining The Test Results from The SonarQube Dashboard.

Cumhur Akkaya
11 min readNov 12, 2023

In this article series, I will talk about the installation, concepts, and usage of SonarQube, Trivy, OWASP Dependency Check, OWASP ZAP, and JaCoCo. Also, I will show you step-by-step how to use them in practice, with hands-on.

In this article, we will integrate the SonarQube Server with Postgresql Database into the Azure Pipeline that runs a microservice Java application in it. Then, we will create and run the Azure pipeline for SonarQube analysis. Finally, we will examine and evaluate the test results in the SonarQube dashboard.

The article will cover the following topics:

1. Integrating SonarQube into Azure DevOps Pipelines
1. a. Installing SonarQube extension for Azure DevOps
1. b. Generating a New Token for Your Project
1. c. Adding a New SonarQube Service Endpoint to Your Azure DevOps Project
2. Configuring Azure Pipelines
2. a. Creating an Azure Pipeline
2. b. Selecting Your Source Code Repo
2. c. Adding and Preparing “Maven” Task
2. d. Adding a New “Java tool installer” Task
2. e. Adding and Preparing SonarQube “Prepare Analysis Configuration” Task
2. f. Adding and Preparing “Publish Quality Gate Result” Task
2. g. Enabling Continuous Integration in Azure Pipelines
3. Running Azure Pipelines for SonarQube Analysis
4. Examining and Evaluating The Test Results From The SonarQube Dashboard
5. As a result
6. Next post: “DevSecOps-3: Code Coverage and Running Jacoco Plugin in Sonarqube and Project’s pom.xml File,

The Fourth post: “DevSecOps-4: Running Sonarqube Scanner, OWASP Dependency Check, Jacoco, and Trivy in Jenkins CI/CD Pipeline.
7. References

If you like the article, I will be happy if you click the Medium Follow button to encourage me to write more, and not miss future articles.

Your clapping, following, or subscribing helps my articles to reach a broader audience. Thank you in advance for them.

In this article series, I will talk about the installation, concepts, and usage of SonarQube, Trivy, OWASP Dependency Check, and JaCoCo. To talk about them briefly;

SonarQube is a leading code quality and security tool used by over 400,000 organizations worldwide. The tool supports 30+ programming languages and offers a range of code analysis features, including static code analysis, security testing, and tracking of best practices (1a). It is a self-managed, automatic code review tool that helps for Clean Code (1b). It is an open-source platform for continuous code quality inspection that includes static code analysis for identifying security vulnerabilities, as a Static Application Security Testing (SAST) tool (2). It also provides a dashboard for metrics and integration with development pipelines.

Trivy is a comprehensive and versatile security scanner (3). It is an open-source vulnerability scanner for containers and other artifacts, such as operating system packages and application dependencies. It scans container images and provides detailed reports on any vulnerabilities detected, including their severity and remediation steps (2). I will use Trivy as a Container Security Tool in this article series. It identifies security vulnerabilities in container images and file systems, supporting multiple package managers and CI/CD integration for enhanced container security (4). It also finds vulnerabilities & IaC misconfigurations, SBOM discovery, Cloud scanning, Kubernetes security risks, and more.

OWASP Dependency Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies (5) and identifies known vulnerabilities in project dependencies (2). It scans project dependencies for known vulnerabilities and generates reports, helping developers address security issues in third-party libraries.

OWASP ZAP: is a free Dynamic Application Security Testing (DAST) tool. OWASP ZAP (Zed Attack Proxy) is an open-source web application security scanner that helps you identify and find security vulnerabilities in web applications (2).

JaCoCo stands for “Java Code Coverage”. It is a tool for measuring and reporting code coverage reports for Java projects. JaCoCo uses class file instrumentation to record execution coverage data. Class files are instrumented on the fly using a so-called Java agent (6). It based on Java byte code and therefore works also without source files.

In the previous article, we talked about the topic of “Installing and Running Sonarqube and Creating a SonarQube Project”. We learned detailed information about the SonarQube Server and installed the SonarQube with the Postgresql Database into an Ubuntu server in the cloud. Finally, we ran SonarQube and created a SonarQube project. The link’s article.

Now we will continue the article from where we left off.

1. Integrating SonarQube into Azure DevOps Pipelines

1. a. Install SonarQube extension for Azure DevOps

From your Azure DevOps instance, navigate to the Visual Studio Marketplace and install the SonarQube extension by clicking the Get it free button, as shown in Figures 1–2.

Figure 1
Figure 2

1. b. Generating a New Token for Your Project

Navigate to “SonarQube server > Administration > Security > Users”, and then click on the tokens icon, as shown in Figure 3.

Then, give a name to the token: sonar-aks-project and click Generate

Copy the created token, it will look like this: sonar-aks-project-token: xxxxxxxxxx, you will need it later. Finally, click Continue to proceed.

Figure 3

1. c. Add a New SonarQube Service Endpoint to Your Azure DevOps Project

In Azure DevOps, go to Project settings > Service connections. (7)
Add a new service connection of type SonarQube, as shown in Figure 4.

Figure 4

Enter your SonarQube server URL, as shown in Figure 16. It is for me: http://20.127.210.13:9000

Enter an existing token, Enter a memorable connection name. Create the service connection, as shown in Figure 5.

Figure 5

Our service connection named “sonarqube-aks-2" has been created, as shown in Figure 6.

Figure 6

2. Configuring Azure Pipelines

2. a. Creating an Azure Pipeline

Click on the “New pipeline” button, then, “Use the classic editor” button in order to create an Azure Pipeline for our Java project, as shown in Figure 7.

Figure 7

2. b. Selecting Your Source Code Repo

Select your Source Code Repo containing our Java project, as shown in Figure 8. For me, I selected the “devsecops” repository in Azure Repos.

Figure 8

2. c. Adding and Preparing “Maven” Task

Add a Maven task for our Java project, as shown in Figure 9.

Figure 9

Then, configure the Maven task, as shown in Figure 10.

Note: Don’t forget to specify the path to the pom.xml file.

Figure 10

2. d. Adding a New “Java tool installer” Task

Add “Java tool installer” task in Azure Pipelines, as shown in Figure 11. Then, under JDK version, select 11 (or higher) (Note: I used the Java11 version because my Java application also gave errors in the Java17 version.), under JDK architecture, select x64, under JDK source, select Pre-installed, as shown in Figure 11.

Figure 11

2. e. Adding and Preparing SonarQube “Prepare Analysis Configuration” Task

Add the “Prepare Analysis Configuration” task in Azure Pipelines, as shown in Figure 12.

Figure 12

Enter a display name, as shown in Figure 13. Select the SonarQube server endpoint we created in Step “1.c.”

Then, choose “Integrate with Maven or Gradle” to run the analysis. Finally, expand the “Advanced section” and add the Additional Properties with the following snippet, as shown in Figure 13.

Note: They must be your project name.

sonar.projectKey=sonar-aks-projects
sonar.projectName=sonar-aks-projects
Figure 13

2. f. Adding and Preparing “Publish Quality Gate Result” Task

Add a new “Publish Quality Gate Result” task to publish SonarQube’s Quality Gate results on your build pipeline summary (optional), as shown in Figure 14.

Figure 14

Leave values as default, as shown in Figure 15. Our Azure Pipeline is now ready for SonarQube analysis.

Figure 15

2. g. Enabling Continuous Integration in Azure Pipelines

Under the “Triggers” tab of your pipeline, check “Enable continuous integration” and select the “main” branch, as shown in Figure 16.

Thus, we will ensure automatic triggering. When something is pushed to the main branch, the Azure pipeline will automatically be triggered and start running.

Figure 16

3. Running Azure Pipelines for SonarQube Analysis

Click on the “Save & queue” button in Azure Pipelines to analyze with SonarQube our Java application code, as shown in Figure 17.

Figure 17

Click on the “Save & queue” button to start SonarQube Analysis, as shown in Figure 18.

Figure 18

Our pipeline started running, as shown in Figure 19. Click on the “Apply Job 1” to see the pipeline flow.

Figure 19

Our pipeline successfully completed all the tasks we finished the “devsecops pipeline”, as shown in Figure 20.

Figure 20

4. Examining and Evaluating The Test Results From The SonarQube Dashboard

Click on the “Projects” button in the SonarQube Dashboard, and then select our project “sonar-aks-projects”, as shown in Figure 21.

Figure 21

“sonar-aks-projects” project home page is opened, as shown in Figure 22.

Figure 22

We can see SonarQube analysis results in the “Overall Code” section, as shown in Figure 23.

Figure 23

Projects are evaluated on SonarQube with letter grades, as shown in Figure 23.

We can evaluate the results on the Project screen (in Figure 23) as follows: (8)

Quality Gate: It decides whether our projects are successful or unsuccessful as a result of sonar scanning. Our result: “Passed”, as shown in Figure 24.

Figure 24

Reliability (Bugs): It marks points in the scanned code that need to be corrected and may cause problems in the future. Our result: “A”, as shown in Figure 25, the Reliability rating is A when there are no bugs.

Figure 25

Vulnerability (Security): It indicates findings that may create a backdoor according to best practice security rules. Our result: “D”, as shown in Figure 26, Security rating is D when there is at least one critical vulnerability.

Figure 26

Security Hotspot (Security Review): It indicates security findings that should be reviewed. It requires review to prevent security vulnerabilities. Our result: “E”, as shown in Figures 27–28, the Security Review rating is E when less than 30% of Security Hotspots are reviewed.

Figure 27
Figure 28

Maintainability: I can easily update this project and use it with new technologies. Our result: “A”, as shown in Figure 29, the Maintainability rating is A when the technical debt ratio is less than 5.0%

Figure 29

Coverage: It shows what percentage of the code has been tested with unit testing. Our result: “22.2%”, as shown in Figure 30, Coverage on 245 Lines to cover in our source code.

Figure 30

Duplication: It shows how many blocks have been copied exactly in the source code. Our result: “Green”, as shown in Figure 31, 1.1%Duplications, Duplications on 1.8k Lines.

Figure 31

Code Smells: It indicates fixes for code maintainability, as shown in Figure 32. It marks the points required for clean code that need to be resolved in order to reduce maintenance and readability costs in the code in the future.

Figure 32

Debt: It shows the approximate time cost to fix code smells, as shown in Figure 33.

Figure 33

5. As a result

We integrated the SonarQube Server with Postgresql Database into the Azure Pipeline. Then, we created and ran the Azure pipeline for SonarQube analysis. Finally, we examined and evaluated the test results in the Sonarqube dashboard.

If you liked the article, I would be happy if you click on the Medium Following button to encourage me to write and not miss future articles.

Your clap, follow, or subscribe, they help my articles to reach the broader audience. Thank you in advance for them.

For more info and questions, please contact me on Linkedin or Medium.

6. Next post

In the next post, “DevSecOps-3: Code Coverage and Running Jacoco Plugin in Sonarqube and Project’s pom.xml File”, as shown in Figure 34. We will learn detailed information about Code Coverage and Running Jacoco Plugin. Then, we will integrate the Jacoco Plugin into the java application’s pom.xml file, and run the Jacoco plugin in Sonarqube. We will do them practically and step by step.

Figure 34— “DevSecOps-3: Code Coverage and Running Jacoco Plugin in Sonarqube and Project’s pom.xml File”

In the fourth post, “DevSecOps-4: Running Sonarqube Scanner, OWASP Dependency Check, Jacoco, and Trivy in Jenkins CI/CD Pipeline.”, as shown in Figure 35. We will integrate Sonarqube Scanner, OWASP Dependency Check, Jacoco, and Trivy into Jenkins, and run them in Jenkins CI/CD Pipeline in order to analyze the codes and images of a Microservice Java application. We will do them practically and step by step, as shown in Figures 36–37–38.

Figure 35 - “DevSecOps-4: Running Sonarqube Scanner, OWASP Dependency Check, Jacoco, and Trivy in Jenkins CI/CD Pipeline.”
Figure 36 — Sonarqube Analysis and Quality Gate Results
Figure 37 -OWASP Dependency-Check Results
Figure 38 -Trivy Results

Happy Clouding…

Don’t forget to follow my LinkedIn or Medium account to be informed about new articles.

--

--

Cumhur Akkaya

✦ DevOps/Cloud Engineer, ✦ Believes in learning by doing, ✦ Dedication To Lifelong Learning, ✦ Tea and Coffee Drinker. ✦ Linkedin: linkedin.com/in/cumhurakkaya