SonarQube
SonarQube is a shared static code analysis tool hosted on the ABB LAN network.
Where to find the tool
SonarQube as a web-based tool is hosted in a web server available under the following link - https://xc-s-zw00510.xc.abb.com/projects .
There is also a client-side tool designated for Visual Studio and Visual Studio Code IDE integration called "Sonar Lint" - which is available under the following link https://www.sonarlint.org .
Description
SonarQube is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities in 20+ programming languages. SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities.
SonarQube can record metrics history and provide evolution graphs. SonarQube provides fully automated analysis and integration with Maven, Ant, Gradle, MSBuild, and continuous integration tools (Azure DevOps, Jenkins, etc.).
SonarQube integrates with Eclipse, Visual Studio, and IntelliJ IDEA development environments through the SonarLint plug-ins, and also integrates with external tools like LDAP, Active Directory, GitHub, and others. SonarQube is expandable with the use of plug-ins.
Motivation
SonarQube identifies all types of issues that may come during the development cycle covering all aspects of security issues, vulnerabilities, and quality defects. SonarQube improves code maintainability in the short and long run.
The cyber security team together with the DevOps team did a tool evaluation which is available in Microsoft Team Share.
How to analyze the code
With proper integration, the tool will inform the developer early during development on the fly, so the developer can see how to correct problems even before preparing a pull request. The second analysis is done during the pull request process, via a mechanism called pull request decoration. This prevents from put on master branch unwanted quality issues.
New and changed code
SonarQube is presenting information about new and changed code which is going to be put on the master branch - this is called "new code", and is blocked on pull requests until all quality conditions are met. This way developers can distinguish between the existing code base and new changes. Blocking mechanisms ensure the focus of quality practices among the teams.
Existing code base
SonarQube presents information about existing code quality, which is in the form of a web page dashboard. It is organized as a flag that simply informs about two states (passed, failed).
New versions
This is the responsibility of the team administering SonarQube inside ABB.
Rule set
Configuration of the rule set is under the SonarQube administrator's responsibility.
Official documentation regarding rules in SonarQube can be found under the following links:
Storage
All SonarQube rules are stored on the server.
Defined rules for each programming language can be found in the 'Rules' tab on the SonarQube web page.
SonarQube Rules in ABB Instance
Version control
This is the responsibility of the team administering SonarQube inside ABB.
Add/remove rules
Configuring the rule set is under the SonarQube administrator's responsibility.
Official documentation regarding rules in SonarQube can be found under the following links:
New rule set from new tool version
The built-in rules get updated when either the version of SonarQube is upgraded or the language-specific extensions are updated. The custom rulesets are updated and managed by teams. SonarQube team normally sends out notifications regarding any planned upgrades. The product page of SonarSource maintains a changelog of all the changes.
SonarQube update is the responsibility of the SonarQube administration team.
Standards
The SonarQube Quality Model has three different types of rules: Reliability (bug), Vulnerability (security), and Maintainability (code smell) rules.
The vast majority of security-related rules originate from established standards: CWE, SANS Top 25, and OWASP Top 10.
Official documentation regarding security rules in SonarQube can be found under the following link:
Monitoring
Monitoring is done on the SonarQube server, where different dashboards can be used to view different issues, statuses, or severities. A pull request in Azure DevOps shall be set up with a required check that blocks the pull request from completing while there are unhandled SonarQube issues in the code.
Severity levels
This is specific to the tool, severity metrics are set up automatically based on rules defined in the software. Then developer team can change that to reflect real-life situations. (quality issue, false positive).
How to handle deviations
In case of bugs, security hotspots, and vulnerabilities those can be handled with appropriate status: To review, Fixed, Safe.
In case of code smell deviation it can be handled as well with appropriate status: Open, Confirm, Resolve as fixed, Resolve as false positive, Resolve as won't fix. The overall status of the analysis is updated accordingly.
Deviations in code coverage are "work in progress".
Materials
Materials and recordings regarding SonarQube are available in the DevOps team in Microsoft Teams.