Static Code Analysis
What is Static Code Analysis?
Static Code Analysis is a technique where an automated suite of tools performs code reviews to ensure quality and adherence to style guidelines, and to highlight any possible vulnerabilities or bugs.
These tools find code issues by analysing source code, without needing to compile or run the code. Static code analysis differs from dynamic code analysis in this respect; dynamic code analysis requires the code to be compiled and run in order for it to be analysed.
Traditionally, static code analysis tools work better with strongly-typed languages. These provide more explicit user data paths, meaning the tooling can track data sinks and potentially tainted data more efficiently.
Benefits
Tooling can vastly improve the standardisation of code and quality across a project, one pull request at a time. It also automatically covers the entire code base to which it's applied, meaning any areas not covered by automated test suites will benefit from some level of analysis.
Static code analysis can also reveal common code deficiencies, like incorrect variable scoping, not closing files after use, or improperly handling memory.
Additionally, static code analysis rules can often be closely related to security, allowing teams to improve their level of confidence in their ability to defend against OWASP Top 10 vulnerabilities quickly.
Drawbacks
It's worth considering that static code analysis is an imperfect science; the tooling cannot interpret developer intention. In addition, tooling suites are usually not able to find configuration issues, due to the code not being compiled or run at the point of analysis.
Whilst we recommend using these types of tools, it's worth being aware of their limitations and shortcomings. Static code analysis tooling can quickly generate large numbers of false positives or uninteresting warnings. A way around this is to introduce rules to your codebase slowly, and after careful review. This systematic and deliberate process allows you to involve engineers and stakeholders in each decision, and ensures all parties understand the reasoning behind (and desired outcomes of) each change to the rules.
Tooling cannot enforce all coding rules on a project; they are not a silver bullet to solve all future stylistic disputes. To maximise the benefit of tooling, ensure you can codify most of your style guides.
Choosing your tooling
There are several key areas you should take into account when selecting tooling to support static code analysis. It should run rapidly, in a continuous integration setting, and report differing levels of issues directly against the codebase for fast triage (preferably annotating the line of code directly!). It should also run locally within the development environment, so an engineer gets quick feedback on potential issues.
It should be quick and easy to suppress a rule and review multiple issues at once. The tool should support your languages of choice and have a wide range of default rules that can be slowly enabled as you roll out the tooling.
Tools on offer
SonarQube is one of the leading tools in this area. It can have a negative reputation, but we believe this is due to poor rule management and roll-out, rather than because the system is problematic.
If using Java, we've had success with SpotBugs, PMD, and CheckStyle.
If using Javascript, try ESLint - we like the Airbnb rules.
NIST has also supplied a comprehensive list of tools if you're looking for a different language or feature set.