Static Code Analysis

Software consists of text that people write: the source code. Static code analysis means having this text checked by a program without first starting the software. The checking program only reads, it doesn’t compute anything. It looks for spots that are typical of errors. The opposite of this is testing in operation: there, you start the software and see whether it does the right thing. A comparison helps: static analysis is like proofreading an essay. A test in operation is like reading aloud in front of an audience.

Why this matters

Errors in software become more expensive the later they are found. A problem that a tool reports in seconds costs almost nothing. The same problem in live online banking can cost millions. Static analysis shifts the finding of errors as far forward as possible.

This is especially important for security vulnerabilities. Many well-known attacks always exploit the same patterns in code. A tool can reliably recognize such patterns. In industries with strict regulations, such as aviation or medical technology, static analysis is therefore mandatory.

A second point is volume. Large projects have millions of lines of code. No human reads through all of it. A tool manages to do so anew with every change.

How it works

First, the tool breaks the source code down into its components. It recognizes where a function begins, what variables exist, and how statements relate to one another. This produces a tree structure that maps the program’s construction. The actual checks then operate on this structure.

The simplest checks are pattern matches. They report, for example, a variable that is created but never used. Such tools are called linters. More sophisticated methods track where a value comes from and where it flows. This is how, for instance, one finds user input that ends up unchecked in a database query. That is exactly a classic security vulnerability.

The method has a fundamental limitation. Whether a program behaves correctly in every conceivable case cannot generally be derived from the text alone. Tools must therefore estimate. Two kinds of inaccuracy follow from this. Some reports are false alarms, so-called false positives. Some genuine errors are overlooked. Too many false alarms are dangerous, because developers then start to ignore all reports.

What’s new is that language models are now contributing to this task. They also recognize problems for which no one has written a fixed rule. In exchange, their statements are less reliable than those of classic rule sets.

Where you encounter the term

Anyone who programs sees static analysis constantly. Modern programming environments underline faulty spots as you type, similar to how a word processor flags typos. That is static analysis working in the background.

In companies, it runs automatically with every code change. If it raises an alarm, the change is not merged. Well-known providers are SonarQube, Snyk, and Checkmarx, along with GitHub’s checking tools. Security firms of this kind are regularly acquired for large sums, which is why the term also turns up in financial news.

Currently, the topic is getting extra attention because AI tools are writing a great deal of code. This code usually looks plausible, but it isn’t automatically secure. Static analysis is one of the few methods that can even check such volumes at all.