Static Code Analysis
Static source code analysis is a method for analyzing the source code without executing it. This guide provides relevant information about static code analysis within PCP R&D.
Intended for
Software engineers, security engineers, and release owners.
Introduction
ABB’s Security Development Lifecycle Standard requires static code analysis of at least all new and changed code. If a static analysis tool is available for the language, then such a tool shall be used. The compiler is also a type of static analyzer; however, it analyzes the code for programming language syntax and semantics, while advanced static analysis techniques perform a much deeper analysis of the code to uncover potential run-time defects.
Code on which static code analysis shall be applied
Static code analysis is required for software projects and customized third-party libraries if standard languages such as C/C++, C#, and Java are used. All new and changed code has to be analyzed. When analyzing an existing code base, it is not required to fix all warnings. Instead, a baseline can be made. However, some findings, e.g., security warnings, must be handled. After baselining, only the differences have to be handled when changing the code if this is supported by the tool.
When changing or upgrading the tool, new warnings may appear, and depending on the severity of the warnings, how to handle them must be decided on a case-by-case basis.
Selection of tools
Static code analysis tools shall be chosen for each applicable product or part of the product. See Static Code Analysis Tools for recommended tools. More than one tool can be used since different tools can have different findings. It is recommended to choose tools that can be smoothly integrated into the "build environment" on the desktop or build server.
The tool shall support the applicable standards to the greatest extent to reduce the use of checklist items for manual code reviews. The relevant R&D cluster lead and the release owner are responsible for choosing the tools. To utilize new and improved rules, it is recommended that the latest versions of the tools are used. Each project shall decide which version of the tools to use (the latest or a specific version), but the R&D cluster lead and the release owner have the final responsibility.
If no tool is available for the language, all security checks must be done during manual code review.
Selection of rule set
A rule set shall be chosen for each applicable product. The static code analysis tools will analyze the code based on those rules. It is recommended that the code responsible for a product (e.g., repo gatekeeper in Git) chooses the rule set based on the applicable standards and best practices. If no gatekeeper exists, one or several persons can be responsible for the rules set.
The relevant release owner is responsible for deciding on the rule set. The selected rules shall be defined and placed under version control. The rule set can be specified in the tool's configuration file, if applicable, or in a separate document. For further recommendations and best practices for secure coding, see Secure Coding Guideline, which includes links to programming language-specific coding guidelines.
The rule set must fulfill the security requirements and include checks addressing security vulnerabilities. MITRE lists known weaknesses, and their lists are good input for selecting rules.
CWE Top 25 Most Dangerous Software Weaknesses lists the most common and impactful issues experienced over the previous two calendar years. These weaknesses are dangerous because they are often easy to find and exploit. They can allow adversaries to completely take over a system, steal data, or prevent an application from working.
New rules provided by a tool (e.g. with a new version of the tool) need to be considered continuously. Evidence of which rule sets have been used for the released code must exist.
Documentation
Each product should define and document:
- Which tool(s) to use.
- What rule set(s) to use.
- How the results will be handled.
Each new release can reference this documentation together with any modifications, such as the tool's version, changes in the rule set, or the frequency of running the tool.
Build policy
Developers should run the static code analysis tool and handle warnings before integrating the code.
For an effective static analysis adoption, the static code analysis tool should run periodically on the entire product. The release owner shall define the frequency and it is recommended to run it daily as part of the daily build process.
When using Git, this should be part of the commit rules for the pull request, and it should not be possible to complete the pull request before all warnings have been handled.
Policy for handling deviations
All warnings shall be analyzed and resolved before integrating the code for new and changed code. The number of warnings shall be monitored and controlled. The number of warnings shall decrease over time, i.e., new implementations shall not introduce new warnings.
False positives are reported incorrect warnings; they are not really bugs. The false positives show the analyzer's weakness. Hence, this needs to be communicated to the tool vendors so that they can improve the tool.
If the warning is correct, it must be triaged if it is relevant. Deviations from the rules are acceptable if they are motivated. The motivation shall be put in a comment next to the code that caused the warning, and it is recommended to handle the deviations from the rules before checking in. The code responsible for a product is recommended to approve deviations during code review.
There shall exist evidence of the deviations made in the released code.
If a rule gives too many false positives to be useful or is not helpful for code quality, it is recommended to disable the rule. This does not include mandatory rules if required by standards, e.g., security rules. Otherwise, it can be decided by the code responsible for a product.
Progress monitoring
The project's progress needs to be monitored by assessing the improvements in the code's quality. The metrics established in the beginning could be used to compare the code quality improvement since the previous builds. Based on the progress, action items could be defined for further static analysis activity.
The R&D cluster lead and the release owner are responsible for ensuring that the warnings' status is followed up on during the project and that suitable actions have been taken.
It is recommended that metrics are used to follow up on the status of the static code analysis, e.g., the number of warnings that need to be addressed. It should also be possible to create a report of the remaining warnings and deviations to ensure everything has been handled, e.g. at the end of increments/iterations and before the release.