Streamline code quality: Integrating SonarCloud and SonarQube scanning with Kosli for automated compliance

Static code analysis is an important part of testing your software to ensure it is release-ready. In contrast to dynamic testing, which involves executing your code to find errors, static analysis uses automated tools to “look” through the code, without executing it,  to find potential errors (including potential security issues) and bugs. Since the code does not need to be executed, static testing can begin much earlier in development than dynamic testing. This allows potential issues to be found and addressed as early as possible, reducing their impact and improving the quality of the code.

Two of the most popular static code analysis tools are produced by SonarSource: SonarCloud and SonarQube. The main difference between these two is that SonarCloud is hosted by SonarSource, making it very quick and easy to set up and start scanning; while SonarQube is installed (along with a database) on your own server. This requires more work to set up SonarQube and start scanning, but it gives you more control over your data and environment.

SonarCloud and SonarQube use Quality Gates, i.e. sets of rules for your project, which determine whether your code meets the standards you have set regarding, for example, the amount of duplicated code allowed. This enables you to see at a glance whether your code reaches the level of quality necessary for the project, and if not, what issues need to be fixed.

Leveraging Webhooks for Automated Compliance

Both SonarCloud and SonarQube provide webhooks, which are triggered by completion of a code scan. They offer global webhooks which are defined at the organization level and are triggered by a scan of any project in the org, as well as project-specific webhooks which are triggered only by a scan of that particular project. 

We have developed an integration with Kosli using these webhooks such that, when you scan your project with SonarCloud or SonarQube, the results of the scan are automatically attested to Kosli and contribute to the compliance or non-compliance of your flows and trails. In the example we’ll work through in this article we’ll show how to use this integration to attest SonarCloud scan results to Kosli for cyber-dojo’s differ microservice. Although cyber-dojo uses SonarCloud, the steps are essentially the same for SonarQube.

For our differ repo we create the Flow (differ-ci) and Trail at the start of our Github workflow and attest the artifact when it is created, so that all three are already in place by the time we need them.

Import the repo to SonarCloud

The very first step is to create a sonar-project.properties file in our Github repo. This file specifies the organization name (cyber-dojo) and project key (cyber-dojo_differ) as defined in SonarCloud, and tells SonarCloud that we intend to scan our project using our CI pipeline. 

Now we can import our differ repo by following the instructions to analyze a new project in SonarCloud. This creates a corresponding differ project within SonarCloud. 

Note that it is important to have added the sonar-project.properties file to your repo before you import it - otherwise SonarCloud assumes you want to take advantage of their Automatic Analysis tool, which does not work with the Kosli integration.

Setting up the webhook integration

The next step is to set up the integration via the Integrations page in the Kosli app. 

Clicking the Add Integration button takes us to the Sonar integration page. By changing the status toggle to On, we create a webhook with a webhook URL and secret determined by Kosli.

Next, we need to set up a corresponding webhook on the SonarCloud side. The Kosli integration will work with both global and project-specific webhooks in both SonarCloud and SonarQube; we simply provide that webhook the URL and secret generated by Kosli. Detailed instructions for setting up the Sonar webhooks can be found in our docs.

Configuring our repo to use the Sonar Scanner

The sonar scanner is the tool which actually scans your code. To make this easy, Sonar offers integrations with the major CI systems, including Github Actions, Gitlab CI/CD, Bitbucket Pipelines, and Azure Pipelines, which are simply added as a job or step in the workflow .yml file. The scanner can also be downloaded and run locally via the SonarScanner CLI.

For cyber-dojo, we use the Github Actions SonarCloud integration.

For the scanner to work we need two things:

1. A secret token created in SonarCloud, saved as a Github secret
2. A sonar-project.properties file, as mentioned earlier

Note that if you are using SonarQube rather than SonarCloud, you also need the URL of your server, which can be included in the sonar-project.properties file.

Additional scanner parameters required for Kosli

For Kosli to know where to attest the scan results received from the webhook, we need to provide some additional parameters to the scanner: the name of the Flow and (if relevant) the fingerprint of the artifact to attest the results to. A Trail name and attestation name can also be given.

These parameters can be included in the sonar-project.properties file, or passed as arguments to the sonar scanner (either CI or CLI) using the notation 

\-Dsonar.analysis.kosli_flow=<YourFlowName>

By using the “sonar.analysis.” prefix, we tell the sonar webhook that these parameters should be included as properties in the JSON payload sent to Kosli. This enables Kosli to parse the received JSON to find out where and how the scan results should be attested, with no extra work on your part!

For differ, we pass the parameters to the scanner in the workflow, as can be seen below: 

We specify the Flow and Trail names (which are set as environment variables), the artifact fingerprint, and the name to give to the attestation. This results in a sonar attestation with the name “sonarcloud-scan” being attached to the given artifact, within the given Trail, within the given Flow.

Scanning and Attesting

Now that we’ve created our webhooks and configured the sonar scanner, we’re ready to actually scan our differ project and attest the results to Kosli. This is as simple as triggering the workflow in Github by pushing some code to the repo. As part of that workflow, the SonarCloud Action scans the project.

For the initial scan of a project in SonarCloud no Quality Gate is computed, and there is therefore nothing to attest to Kosli. For all subsequent scans, when the scan is complete, the results appear in the SonarCloud UI and the webhook is triggered. Kosli receives the webhook payload and attests it as a sonar attestation based on the parameters we passed to the scanner. The compliance of the attestation is determined based on whether or not the SonarCloud Quality Gate has passed or failed. 

Above we see the scan results summary within SonarCloud, and the corresponding sonar attestation within the Kosli app. In Kosli, we can see at a glance whether the SonarCloud quality gate has passed or failed (and thus whether the attestation is compliant or not), as well as the status of the various conditions that make up the quality gate. 

If any of these conditions are past the error threshold they will be highlighted and the attestation will be non-compliant, making it easy to see what the problem is and therefore how our code can be improved - an example of this is shown below.

We can instantly see that the quality gate has failed due to a lack of test coverage and a very large number of duplicated lines in the new code. Knowing this, we could quickly find the offending code (a duplicated file) and fix the issue - and differ was back to green!

Sound good? The SonarCloud and SonarQube integration with Kosli is now live, making it easier to ensure your code meets quality standards from the start. This integration not only simplifies your workflow but also gives you greater confidence in the software you’re shipping. Explore it in the app and see how it can enhance your development process