Klocwork
Klocwork static code analysis tool identifies software security, safety, quality, and reliability issues helping to enforce compliance with standards. The tool has many rules to choose from.
This is one of the ABB global SCA tools, and the only one approved for safety.
Where to find the tool
Klocwork can be found here: https://www.perforce.com/products/klocwork
It can be used locally and on a build server. There are Klocwork Desktop plug-ins available, e.g. for Visual Studio and Eclipse.
Description
Klocwork static code analysis tool supports C, C++, C#, Java, and JavaScript. The tool has many rules and collections of rules to choose from. The used ruleset is overlapping with other tools but forms a base and leverages what the tool is capable of.
Motivation
Klocwork identifies critical security and safety vulnerabilities and quality defects and helps developers create more maintainable code.
How to analyze the code
Desktop plugin analysis
C/C++ code: By default, the Klocwork Visual Studio extension runs whenever you save a file. If you prefer, you can use on-the-fly analysis instead so that Klocwork detects issues when you open files and as you type.
C# code: For pure C# or mixed C/C++ and C# solutions, right-click the solution and select Analyze Solution. Or right-click a project and select Analyze Selection. A full solution or project analysis detects both C/C++ and C# issues.
When Klocwork detects issues in a file, you see issue markers on the left and right margins of the editor. The left markers (chevrons) scroll with the text. When Klocwork detects more than one issue on the same line, the left gutter markers display only the highest-priority issue.
Server analysis
An analysis shall be run on the server as part of a pull request or before integrating the code. A full analysis shall be performed regularly, for instance, every night. The issues are listed on the Klocwork server per project.
New and changed code
New and changed code shall be analyzed during the code review, e.g. as part of a pull request.
Existing codebase
It is possible to baseline the existing issues in the codebase. Critical security errors and warnings shall be fixed, other issues are recommended to baseline.
New versions
Klocwork release schedule is one new version each quarter, hence version naming is year.quarter.
The release notes state which Visual Studio versions are supported. When using a newer version one can expect issues with the analysis of STL as Microsoft frequently changes its implementation.
Reevaluate all overrides, done in file overrides.h, to see if the analysis engine has improved. The Modern engine should hopefully be able to parse the code cleanly without workarounds.
Ruleset
Storage
The ruleset for a project is stored in one configuration file together with the code, e.g. in a git repo.
Version control
One configuration file analysis_profile.pconf for each project is placed and version-controlled together with the code.
Add/remove rules
Rules are modified, added, and removed by changing the analysis_profile.pconf file.
New rule set from new tool version
When a new version of the tool has been provided, a tool responsible needs to read the release notes for the new version and consider if new rules should be used in the ruleset. By default, the new rules are normally enabled, which can cause a lot of new issues in the Klocwork analysis. The configuration file should be updated to reflect this.
Standards
Klocwork has checkers for the CWE Top 25 most dangerous software weaknesses, which complies with the standard IEC 62443-4-1.
Monitoring
Monitoring is done on the Klocwork server, where different views can be set up to view different issues, statuses, severities, etc. Issues can be filtered in many ways.
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 new Klocwork issues in the code.
Deviation reports can be produced from Klocwork.
Severity levels
An issue severity is made up of a level from 1 through 10, plus a label such as Warning. Each checker has a default severity. By default, checkers are assigned severities 1 through 4. Custom checkers are assigned severity 4 by default.
The available severity levels and their default labels are as follows:
1 - Critical
2 - Error
3 - Warning
4 - Review
5 - Severity 5
6 - Severity 6
7 - Severity 7
8 - Severity 8
9 - Severity 9
10 - Severity 10
How to handle deviations
Newfound issues that require some sort of deviation shall be commented in the ongoing pull request and resolved by a reviewer:
- Klocwork pipeline finds an issue. The issue ID shall be documented in a comment in the pull request on the failing source code row.
- Handle issue in Klocwork by setting the correct status and in the motivating comment refer to the pull request id. Possible statuses:
- Not a problem: Used for false positives.
- Ignore: suppress issue that can't be fixed in code, or usage of 3rd Party API, etc.
- Defer: avoid using it, but present due to legacy issues.
- Pull request reviewer (preferable the team member being familiar with the code) resolves the comment if motivation in Klocwork is sufficient. The reviewer also adds a "Reviewed by N N" statement to the Klocwork comment.
ABB Klocwork security compliance
The ABB taxonomy 'ABB minimum security checks' in Klocwork can be used to fulfill the ABB Minimum Cyber Security Requirements in Klocwork.
Klocwork has checkers for the CWE Top 25 most dangerous software weaknesses.