Static Application Security Testing

Every program consists of text that humans have written: the source code. This text often contains errors that can later give attackers access to data. Static Application Security Testing is a method that searches exactly this text for such errors. The word “static” means here: the program is not started, only read. A testing tool goes through the code line by line and flags suspicious spots. The comparison with a spellchecker fits well, except that here the search is not for typos but for security problems.

Finding errors while they are still cheap

A security vulnerability costs more the later it is discovered. As long as the code is still with the developer, the fix is a matter of minutes. If the software is already installed at customers' sites, it requires emergency updates, communication, and sometimes reports to authorities. This is exactly why companies deploy SAST as early as possible.

A second reason is the sheer volume. Large applications have millions of lines of code, with new changes constantly being added. No team can check that completely by hand. A tool can complete the review in minutes and always reports the same error patterns, without ever getting tired.

On top of that comes regulatory pressure. Anyone supplying software for banks, government agencies, or medical devices often has to prove that the code was systematically checked. A SAST report is such proof. For providers of security tools, this is a growing market, which is why the term also appears in business news.

How the tool reads the code

First, the tool breaks the source code down into its components and builds a kind of structure tree from them. This tree shows which parts of the program call each other and where data travels back and forth. Based on this structure, the tool searches for known error patterns, similar to how a search function looks for words, except here it looks for relationships.

A typical pattern is the path from an input to a dangerous command. If a user types something into a search field, and this text ends up unfiltered in a database query, they can manipulate the query. The tool traces such chains across the code. It warns when there is no check between the input and the command.

Because the program never actually runs, the tool does not know the real operating scenario. That is why SAST tools report many spots that are harmless in practice. These false alarms are called false positives, meaning incorrect hits. Conversely, SAST fails to find some vulnerabilities at all, such as wrong passwords in server operation. The complement to this is called DAST, Dynamic Application Security Testing: here, the running application is attacked from the outside. Modern tools additionally use language models to evaluate findings and formulate correction suggestions.

SAST in developers' everyday work and in the news

In many companies, SAST runs automatically as soon as someone submits code. The check is part of what is known as the pipeline, that is, the chain of automated steps from code to finished application. If the tool finds something serious, the change is blocked. The developer receives a list with line numbers and a description of the problem.

Well-known tools of this kind include SonarQube, Checkmarx, Semgrep, and GitHub CodeQL. Some are usable for free, others cost several hundred euros per developer per year. In corporate announcements, the term is usually read in connection with acquisitions: large providers buy smaller analysis firms to round out their security offerings.

Even as a student, you can try this out. Anyone who puts their own project on a platform like GitHub can enable code checking there. A common misconception, by the way, is that a clean SAST report means secure software. It only means: this one type of check found nothing.