SonarQube Training

Developer Session
A journey in the land of code quality and security

@sonarsource | © SonarSource 2015-2022

Agenda
Developer Session

● Scanner integration
● Key metrics
● Rules and Quality Profiles
● Quality Gates
● Configuring Clean as you Code and the New Code Period
● Issue Management
● Working practically with SonarQube SAST results
● Branch Analysis / Pull Request decoration (Merge Request)
● SonarLint
● Q&A
Scanners
Scanning is simple and complex at the same
time
 Scanner workflow
SQ
Web Server host
CI/CD host

1. Download project info

Compute Search
Scanner (incl. Engine Server
language 3. Upload analysis
analyzers) report
4. Quality Gate, PR decoration

2. Parse and analyze source files DB

Source Files
host
Let’s start simple: CLI scanner

● Invoked as a command line utility by your DevOps platform (or standalone)

● Used for languages where SonarQube doesn’t need compile-time artefacts
○ Everything except Java and .NET
● Also used for C, C++, ObjectiveC (see later)
● Command line options added using -D<option>=<value>

CLI scanner

sonar-scanner [options]
Java-ish build systems

● Making it easy to scan using the same tool you use to build
● Each plugin provides a SonarQube scanning target
● Java analysis requires compile-time artefacts (retrieved from your config)
● Command line options added using -D<option>=<value>

Maven Gradle

mvn sonar:sonar [options] gradlew sonarqube [options]

.NET scanning

● Special scanner must be used for .NET solutions

● Integrates with MSBuild and the Roslyn compiler
● Requires a full, clean build of your solution
● Command line options added using /d:”<option>=<value>”
.NET scanning
.NET Framework 4.6+ (Windows)
SonarQube.Scanner.MSBuild.exe begin /k:"projectKey" /d:"sonar.login=<AuthToken>" [optional
parameters]

MSBuild.exe <path to solution.sln> /t:rebuild

SonarQube.Scanner.MSBuild.exe end /d:"sonar.login=<AuthToken>"

.NET Core Global Tool (Linux)

dotnet sonarscanner begin /k:"project-key" /d:"sonar.login=<AuthToken>" [optional parameters]

dotnet build <path to solution.sln>

dotnet sonarscanner end /d:"sonar.login=<AuthToken>"

Full parameter list: https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-msbuild/

C, C++, Objective-C
Build Wrapper

build-wrapper --out-dir <some_dir> <build command>

sonar-scanner -Dsonar.cfamily.build-wrapper-output=<some_dir>

Compilation database

<build command that generates compile_commands.json>

sonar-scanner -Dsonar.cfamily.compile-commands=compile_commands.json

Compilation DB: Compilation database | SonarSource blog

Parameters: C/C++/Objective-C | SonarQube Docs
Example repos: https://github.com/sonarsource-cfamily-examples
Note: multi-threading and cached analysis options available
DevOps pipeline integrations

Dedicated tasks and pipeline support:

● GitHub Actions
● BitBucket Cloud Pipelines
● GitLab CI/CD Pipelines
● Azure DevOps extension
● Jenkins plugin
Azure DevOps Extension
1. Define your service endpoints and 2. Easy tasks to create your build jobs
credentials centrally
Azure DevOps Extension
Prepare Analysis Task to select MSBuild, Maven,
Gradle or Standalone scanner and specify
analysis properties

Optional Publish Quality Gate Task to report

QG in Azure DevOps
Branch and PR/MR auto-detection

Simpler pipelines without need for conditional logic:

● GitHub
● GitLab
● Azure DevOps
● BitBucket
● Jenkins (using multi-branch plugin)
● CodeMagic
Failing pipelines

Your decision whether to fail pipelines:

● Jenkins: webhooks (lightweight, no polling)
● GitHub Actions: SonarQube Quality Gate Check
● BitBucket Pipelines: SonarQube Quality Gate Check
● Others: sonar.qualitygate.wait=true
Narrowing the Focus

Generated and third-party source code

● Usually not under your control
● Often has many issues that ‘pollute’ your SonarQube projects
● General rule: don’t scan this code
● Or scan once in a separate project
Excluding code - sonar.exclusions, sonar.test.exclusions
Including only some code - sonar.inclusions, sonar.test.inclusions
Key metrics
Focus on what matters first
Project key metrics
New Code first!
Security and Reliability Ratings
A matter of severity

Severity Rating
Rating represents the single
highest Severity Vulnerability Blocker E
or Bug in the code period
Critical D

Major C

Minor B

Info (or No issues) A

Tech Debt ratio and Maintainability Rating
A matter of code smell density
● Tech Debt (TD): Total effort to fix all CODE SMELL issues
● TD Ratio: Tech Debt / Effort to entirely rewrite the code
Tech Debt Ratio Maintainability Rating
● Example: project with
○ 118 code smells → 1,120 minutes of Technical Debt, 0 - 5% A
○ 1,500 LoC → Total rewrite effort =
5 - 10% B
1500 x 30 min = 45,000 min
10 - 20% C
● Tech Debt Ratio = 1120 / 45000 = 2.5%
20 - 50%
● Maintainability Rating: A D
> 50% E
Security Review Rating
How are you doing on review?

Reviewed Rating
SonarQube 8.1+
< 30% E
Rating represents the
percentage of hotspots 30 - 50% D
reviewed
50 - 70% C
Separate ratings for overall
code and New Code 70 - 80% B

>= 80% A
 Portfolio key metrics

% of projects Passed
● > 80% => A Average of underlying projects ratings
● > 60% => B ● Unweighted
● > 40% => C ● All projects under the portfolio at any depth (not portfolios and projects only 1 level below)
● > 20% => D
● <= 20% => E
Line and coverage metrics Lines = 14
Lines of Code (LOC) = 9 LOC = 9 / 14 = 64% of lines
Comment lines = 2 Comment Density = 2 / (9 + 2) = 18%
Lines to cover = 5 Lines to cover = 5 / 9 = 55% of LOC
Conditions to cover = 2

1 /*
2 1 * SonarQube size metrics
3 */
4
5 1 1 public class CoverageMetrics {
6
7 2 public float f(int i) {
8 3 2 2 int k = 0; /* default */
9 4 3 if (i != 0) {
10 5 4 1 k = 1;
11 6 2 }
12 7 5 return (float)i/(k+1);
13 8 }
14 9 }
 Coverage Line coverage = Lines covered / Lines to cover
Condition coverage = (Cond true + cond false) / 2 * branches
(Overall) coverage = (Cond true + cond false + covered lines) / (2 * branches + exec lines)

Lines to cover = 5
Conditions to cover = 2 Unit Test 1: assertEquals(0.5, c.f(1), 0.0);

/* Line coverage = 5 / 5 = 100%

Cond coverage = (1 + 0) / 2 = 50%
* SonarQube size metrics Overall coverage = (1+0+5) / (2+5) = 85.7%
*/

Unit Test 2: assertEquals(0.0, c.f(0), 0.0);

1 public class CoverageMetrics {
Line coverage = 4 / 5 = 80%
Cond coverage = (0 + 1) / 2 = 50%
public float f(int i) { Overall coverage = (0+1+4) / (2+5) = 71.4%
2 int k = 0; /* default */
3 if (i != 0) { UT1 + UT2
4 1 k = 1;
Line coverage = 5 / 5 = 100%
2 } Cond coverage = (1 + 1) / 2 = 100%
5 return (float)i/(k+1); Overall coverage = (1+1+5) / (2+5) = 100%

}
}
Rules and quality profiles
Defining your quality governance
Quality Profile best practices

● One or a few QP per language only

● Set an organizational baseline and use QP inheritance
● If using LATEST, revisit QP on a periodic basis
Quality Profile management

● Two key options

○ Inherit (from Sonar Way or your own baseline)
○ Copy (removes automatic inheritance)

● Compare function available to measure drift from baseline

Quality Gates
Defining your quality governance
Quality Gate best practices

● One or a few Quality Gates only

● Use metrics on new code
● A reliability rating (0 bugs)
● A security rating (0 vulnerabilities)
● 100% hotspots reviewed
● Set thresholds that are challenging but reachable,
then tighten criteria progressively
 Quality Gates best practices

6 Key project metrics:

6 Key Quality Gate criteria…

(at least)

… On new code, to adhere to CAYC paradigm

Setting the right new code period
Well tuned new code period leads to better code quality

New code period should be

● Long enough to have time to fix issues before they
fall into the “legacy” period
● Short enough to enforce fixing issues before they
accumulate too much
● Typically between 2 weeks and 3 months
But… what’s the new code ?
4 different configurations possible

● Previous Version ● Number of days

○ Best option if compatible with ○ Sliding window for new code
your versioning scheme ● Specific Analysis
○ Align New Code period with
○ Specific Analysis in a given
releases/sprints
○ Fully automatic branch chosen as baseline
Changes considered as New
● Reference Branch ○
Code
○ Specific branch chosen as
○ Can be set up at branch level
baseline
○ Changes considered as New only
Code
 But… what’s the new code ?
4 different configurations possible
Project
scans
1.0 1.1 1.2 2.0
Previous
version

Nbr of Days
28 days Favor previous_version
whenever possible
main

Reference main
Branch
Feature Branch
April 29th at 3PM

Specific April 29th at 3PM

Analysis
CAYC corollary: Respect Quality Gates

● CAYC approach depends on strict enforcement of

Quality Gate
● Don’t reset New Code period on a failed quality gate
Issue Management
Because false positives happen
Issue management
Resolving issues the right way

Automatic resolution
● Just fix the code 😃
Manual resolution
● Administer issues permission
required
● False positive
● Won’t fix
● Never reopened (in that
location)
Multiple issue locations
Managing complex data flow issues

● SonarQube highlights
data flow
● Cross-file analysis
● Helps you decide
where and how to fix
Working with Security
Injections reporting UI and Security hotspots
workflow
Security
What we do and don’t do

In the
Primarily for
SAST DevSecOps
Developers
pipeline
Auditors

Specific
DAST SCA Fast !
process
Security: What we detect
OWASP Top 10 Security Risk Categories

A1 A2 A3 A4

Injection Broken Auth Data Exposure XXE

A5 A6 A7 A8

Broken Access Security XSS Insecure

Control Misconfiguration Deserialization

A9 A10

Components with Insufficient Logging

Vulnerabilities & Monitoring
Vulnerabilities
Fix Security Risks
Security Hotspots
What are they ?
Analyzer has identified a
security risk...

→ VULNERABILITY

→ FIX

Developers should be aware

they are writing
security-sensitive code...

→ HOTSPOT

→ REVIEW
 Hotspot lifecycle Progress indicator

Dedicated tab

Sorted by
priority

New workflow
Security Rating
Overview of code security

Severity Rating
Projects
Highest severity Vulnerability in the Blocker E
code period
Critical D

Major C
Portfolios
Average of the Security Ratings of Minor B
included Projects
Info A
Security Review Rating
How are you doing on Security Hotspot review?

Reviewed Rating
Projects
Percentage of hotspots reviewed in < 30% E
the code period
30 - 50% D

50 - 70% C
Portfolios
Average of the Security Review 70 - 80% B
Ratings of included Projects
>= 80% A
Customization
Support your Proprietary Frameworks

Make the Security Engine aware of your own frameworks by adding:

SOURCES SANITIZERS PASS-THROUGHS SINKS

Input data, vulnerable to Removes malicious Keep track of data Security-sensitive

Injection Attacks content from Input data passing through functions that accept
(tainted data) libraries outside of your Input data
code
Security best practices
Elevate security governance with SonarQube

● Include Security Rating in Quality Gates

● Incorporate Security Hotspot reviews into your
development cycle
● Enforce Security Hotspot reviews using the Security
Review Rating Quality Gate criterion
Branch and PR analysis
Shift left in your feature branches
Why Use Branch Analysis in
SonarQube?
● Issue metadata shared across branches
● Focus on issues created within each branch
● Branch-specific New Code Periods
● Licensing
Scanner Configuration

● sonar.branch.name
● sonar.pullrequest.key
● sonar.pullrequest.branch
● sonar.pullrequest.base

● Automated in supported CI tools pipelines

Issue Behavior

● Issues metadata is synched

○ From parent branch at creation
○ From PR to target Branch after merge
○ To reference branch after merge
● Comment added when issue is synced
“The issue has been copied from branch 'xxx' to branch ‘yyy’.”
Pull request workflow
-- -- Quality Gate
--- --
---
--- --
--- ✅ --- --
---
PR

󰞛 ��🏾
��🏾
💻 💻
Feature
branch Merge

Main branch

Thanks to SonarQube PR decoration

● Developers know about issues in their code before merging

● Information about issues is pushed in the SCM
● It is possible to enforce a policy that PR quality gate must
be passed before pull request can be merged
SonarLint
The ultimate shift left
SonarLint key features
● Supports four major IDE families
○ Plus variants (e.g. Eclipse CDT, IDz/RDz, Topaz)
● On-the-fly analysis of code as you type
● Analysis of changed files or all files
● Connected Mode:
○ Analyze more languages
○ Align Quality Profiles with SonarQube
○ Suppress False Positives / Won’t Fix
○ In-IDE notifications of key events in SonarQube
○ Hotspots and Vulnerabilities in the IDE
SonarLint key features

Issues
highlighted
inline

On-the-fly
analysis

Full rule
documentation
available
 SonarLint connected mode
Configure
rules locally

Bind to Align to project

SonarQube Quality Profile

Manage
advanced
configuration
In-app
notifications
SonarLint connected mode
Open Hotspots in IDE
New Action in
SonarQube UI

SonarLint UI
extended
SonarLint connected mode
Taint Vulnerabilities

Track Tainted
SonarLint Data in Code
extended UI
SonarLint language support
Which languages in which IDE?

● Main language for each IDE

○ E.g. Java for Eclipse, C# for Visual Studio
● Plus supplementary languages where possible
● Plus commercial languages in Connected Mode
○ E.g. COBOL in Eclipse
● Up-to-date list on https://www.sonarlint.org/
○ Choose your IDE to see the list
Questions ?
If you only remember a
few things...
Code Quality must
be a Continuous
Process
for maximum impact
Shift Left
Shorten the feedback loop

Feature branch/ Main/Release

On-the-fly analysis branch analysis
PR analysis

Feedback
2 sec 15 min 24h loop
 Set and
Enforce
Quality Gates
 Update Quality Gates
(and optionally Profiles)
on a regular basis
Feedback is a gift ! Thank you

http://tiny.cc/h21xlz
Questions ?