How to Secure Your Code with Static Code Analysis (SAST)

Code vulnerabilities are one of the most common root causes of data breaches. Just like any other software bug, vulnerabilities are security bugs, leaving a security flaw in the product, allowing adversaries to exploit them to gain access and facilitate an attack or a data breach.
SAST is a type of seurity testing that can help development teams find and fix vulnerabilities in their codebase. In this article we will get familiar with SAST, how it works, and why you should be using it to reduce the attack surface of your application and improve the overall security posture of your application.

What is SAST

Also known as Static Code Analysis, SAST tools scan the source code of the application to find security vulnerabilities within the code. The scan statically analyzes the source code, without compiling or executing it, pointing out problematic code lines that expose the application to security vulnerabilities, along with explanations on the nature of the vulnerability and steps to remediate it.

SAST tools are aimed to be used by the software developers during the development stages of the software. Some tools scan the codebase on a scheduled basis, while others integrate with the Integrated Development Environment (IDE) to provide an immediate feedback loop while the code is being written. The shorter the feedback loop is, the quicker the fix is. And of course, as you shorten the feedback loop, costs decrease as well.

But how does this work? How can we know just from reading the code, that within a certain code fragment lies a possible SQL Injection? How can we tell that a single line of code exposes our application to a path traversal attack?

We can try and train developers to write secured code, with periodic training sessions, or enforce mandatory code reviews by security experts. But security bugs are, well, bugs, and just as we cannot ask developers not to code bugs, we can’t expect them not to code security bugs, it’s just impractical.

SAST comes to the help to solve this problem exactly. It scans the code syntactically, looking for predefined patterns and rules that indicate a security vulnerability. It knows how to deconstruct the syntax of the code to its logical meaning, and so it does not rely on specific syntax to find issues. It can also work with more complex code fragments, testing many combinations of conditional code blocks to find a combination that leads to a vulnerability. Then when it finds a certain pattern, it points out the specific code line, provides explanation about the vulnerability and simple instructions on how to fix it. It really is that simple.

A Real World Example

There’s nothing like a good and simple example to see how simple and great a SAST tool can be for your software development lifecycle and for your security posture in general. According to a recent report by Imperva’s security research team “Lesson Learned from Analyzing 100 Data Breaches” 13.3% of those 100 data breaches initially occurred by a SQL Injection attack. The following example will show how easily we can avoid SQL Injections completely in our codebase if we use a SAST tool to scan our code while we develop it. The code sample below, taken from a simplified bookstore app, gets a book title from the user, and returns the book’s information from the application’s database:

As you can see, the user input is not sanitized and concatenated directly to the SQL query. It is enough to know that the application uses a MySQL database (or make a few tries to discover that) to be able bring back the list of users of the database with their passwords, if only we ask for the title “‘a’ union select User, Password from mysql.user”. Such a title will yield the next SQL query:

Which will return the list of database users with their passwords. That simple and honest mistake in the code exposes our application to a critical vulnerability. Not only can an attacker do a SQL Injection, they can also gain access to the application database. And so that SQL Injection is just a gate for a much broader attack that can leak the entire dataset of the bookstore app, including its users’ personal details. This is by any means a critical vulnerability that puts the entire operation at risk. And this critical vulnerability could have been avoided very easily, with the use of a SAST tool. Now let’s see how this vulnerability could have been avoided if only a SAST tool would have been integrated into the software development lifecycle. Below is a screenshot taken from the SpotBugs IntelliJ IDE extension, an open source SAST tool for Java and other JVM programming languages:

That extension allows software developers to scan the source code as they code it.
It then provides them with the exact location of the vulnerability, some explanations on the nature of it, and instructions on how to fix it, as can be seen in the above screenshot.
It’s that simple.

It can also integrate with the build system, so that when the code is built locally, it will be scanned. Furthermore, it can be configured as a mandatory step to pass before the whole build completes, or in external CI or version control systems as part of a merge request, so that the vulnerable code will not get in the codebase at all.

Integrating a SAST in the Software Development Pipeline

So where exactly should we integrate the code scanning tool?
A SAST tool can be used in several spots along the Software Development Lifecycle (SDLC). As shown above, it can integrate with IDEs and scan the code while it’s being developed. In that case, it can be defined as a mandatory step in the build pipeline, so that the pipeline will fail if a vulnerability exists in the code. This is the leftmost in the SDLC and it is the most recommended one to start with - as it provides software developers with immediate feedback as they code, thus allowing them to quickly fix issues while they code and prevent vulnerabilities from getting in the source code in the first place.
It can also integrate with version control or CI systems as part of a merge request pipeline, as a mandatory step, so that the vulnerable code will not get in the codebase at all. This option has a better enforcement of what gets in the codebase. It can and should come together with the first option mentioned above, mostly as a gatekeeper to the codebase should something have been missed by the software developer.
The last option is to run the tool on a scheduled basis on the codebase itself. This is the less preferred option as it makes the feedback loop longer, increasing the costs of the fix, and leaving the vulnerability in the codebase, which can then find its way to production.

Why SAST is Important for Your Security Posture

SAST is important for your security posture for multiple reasons. First, because it helps to prevent critical vulnerabilities from getting into the codebase of your application, significantly reducing the attack surface of the application, and thus improving the security posture of it.
But more than that, since software developers dramatically outnumber security staff, it is only logical to offload some security responsibilities to the software developers and let them come up with cleaner, more secured applications.