How To Address SAST False Positives In Application Security Testing

What Is SAST?

SAST is an application testing methodology that assesses source code to discover potential design loopholes, using static program analysis to find vulnerabilities. In SAST, the application is scanned without the need to execute its code. It’s also called white box testing.

SAST is one of several approaches used in application security testing (AST). The other main approaches are Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Software Composition Analysis (SCA).

Ideally, SAST is performed in the early stages of the software development life cycle (SDLC). By shifting security left, developers are able to fix issues swiftly without breaking builds or passing defects to the later development stages, where issues are more costly to resolve.

One of the advantages of SAST, as compared to DAST or IAST, is the fact that SAST identifies flaws in 100% of the codebase. For example, the use of inadequate encryption is not something that a DAST or IAST tool can detect, but this is easily detected by a SAST tool.

The Challenge of SAST False Positives

Despite its many benefits, SAST tools have developed a bad reputation of producing a large number of false positive warnings – potential code flaws which, upon further investigation, do not really exist. To demonstrate, here are two typical kinds of problems that arise from these circumstances.

Firstly, project- specific sanitizers. These are measures that are taken to “clean” data in order.  to protect against a vulnerability. Here is an example of a project- spvecific sanitizer for SQL injection:

final var allowedColumns = List.of(“col1”, “col2”, “col3”);

if(allowedColumns.contains(userInput)){

stmt.executeQuery(“SELECT ” + userInput + ” FROM table”)

}

In this example, userInput is a string that comes from the outside: a so-called “taint” or “tainted data.” The data can easily be controlled by an attacker and can cause a SQL injection.

When this tainted data reaches a code location where it might cause harm, then this is called a taint sink. In the code snipped above, the executeQuery method is a taint sink for SQL injection. If no further protection is put in place, you can attack the database by adding a harmful string via userInput and then use it to instigate malicious activity, such as deleting all users, getting administrator permissions, and more.

In general, SAST tools check if there is a path to the taint sink (“a taint flow”) and if it exists, then a vulnerability is detected. However, if some measures are taken on this flow so that only harmless data can reach the sink, then you don’t have a vulnerability. These measures are called taint sanitizers, because they “clean” the tainted data. This way, it is not possible that an attacker can reach the executeQuery call with a harmful string.

Typically, the sanitizer can either be some typical library function (that can be detected out of the box when the tool vendor knows about the library and has predefined a corresponding rule) or it can be something “home-made” or project- specific. In this case, allowedColumns.contains(userInput) is the project- specific sanitizer. It checks that userInput is one of the allowed strings.

Generally, the best way to prevent SQL injection is to use a prepared statement. This isn’t used here, so static analysis tools will report a vulnerability. But in fact it is a false positive, because in this case, a project specific sanitizer is used by whitelisting the input (checking that only one of the expected strings is provided). This is something that no static analysis tool can know in advance.

The second example is that of a context- specific vulnerability. A security tool simply can’t know in advance, if a piece of software is sensitive enough to require authentication and authorization. Therefore many tools report every type of unauthenticated access, thereby generating false positive alerts for unauthenticated access to software that is innocuous. For example, unauthenticated access to software that provides time-of-day lookup is probably not a real vulnerability.

Effects Of SAST False Positives

To understand what a false positive is, it is important to understand the range of test results that a SAST tool can produce. Security testing exercises usually generate the following results:

• True Negative—correctly showing that a vulnerability is not present
• True Positive—correctly showing that a vulnerability is present
• False Negative—not showing that a vulnerability is present, while it actually exists
• False Positive—incorrectly showing that a vulnerability is present, while it actually does not exist.

The goal of any AST tool should be to maximize the true negatives and true positives while minimizing the false negatives and false positives. However, from an engineering point of view, this is hard to do. In practice, most SAST products have been designed to maximize the number of true positives even at the expense of producing a larger number of false positives. It leads to tremendous time wastage as developers hunt down flaws that actually do not exist. What results are the following problems:

Common Causes Of False Positives

There are two main causes of false alarms in SAST tests.

#1 Over assumptions in scanners

Some SAST tools have incorporated too many assumptions in order to provide support for several programming languages. In most cases, these assumptions are generic andcannot accurately apply to all programming languages.

If a bit of source code does not make sense to such tools, or if a dependency is missing, they assume there must be problems with the code. As a result, these static analysis tools produce a large number of false positives.

#2 Poorly designed rules

Some traditional SAST tools are poorly designed and cannot confidently flag vulnerabilities. To compensate for this, they flag vulnerabilities even when there is just a hint that there could be a problem, just to be on the safe side.

For example, some SAST tools search for certain words in string variable names to determine if they contain sensitive data, such as authentication credentials, keys, or passwords.

Let’s look at the following code:

userPasswordLabel.Text = “Please enter your password”;

Although the variable name contains the word “password”, it does not necessarily mean that it contains sensitive information. It’s just a label. If a SAST tool cannot perform further analysis to determine if the variable reveals sensitive data, it could quickly give a false alarm.

How To Avoid SAST False Positives

Let’s look at some ways to conquer the false positives and prevent them from derailing your shift left strategies.

#1 Choose a good tool

Choose a good static analysis tool that is well designed for the job. If you go for any tool without sufficiently assessing its effectiveness, you can waste your time dealing with many false positives instead of resolving real threats.

You need a tool that can perform deep, accurate, comprehensive analysis in your preferred programming language and your tool should cover a wide range of vulnerabilities. A generic tool that is not fine-tuned to your language of choice could produce many false positives for no good reason.

Additionally, go for a tool that can integrate seamlessly within your existing DevOps environment and CI/CD pipeline. This will prevent you from separately configuring or triggering a scan, which can increase the noise of your SAST results.

Read more on how to select the right SAST tool for your organization.

#2 Practice customization

Applying a customized ruleset to a SAST tool will help to decrease the number of false positives. Using a tool’s default settings may not suit the specific needs of your organization.

If you configure a SAST tool to your preferences, it can assist in detecting the right issues and minimizing the false positives. Implementing a tool without customization could produce a lot of junk that may make you miss the real issues plaguing your software.

#3 Filter and prioritize

You can also filter out results that are inconsequential to the well-being of your software. For example, you can ignore results from parts of the software that comprise “dead code” or packages that are not being invoked.

It will help to prioritize the testing results based on what is most important to your organization. You can prioritize them according to the severity of threats, status of the vulnerabilities, and ability to solve the issues. This will allow you to concentrate on fixing the most critical anomalies instead of wasting efforts tackling the issues that have little or no impact.

How Mend SAST Helps

Mend SAST lets enterprise application developers create new applications quickly, without sacrificing security. With Mend SAST, you can effectively reduce the risks and inefficiencies that usually arise from massive alert volume. And you can do it fast. Mend SAST contains a breakthrough scanning engine that produces results 10x faster than traditional SAST solutions. So your developers are not left waiting.

It integrates with your existing DevOps environment and CI/CD pipeline, so developers don’t need to separately configure or trigger the scan. And it’s comprehensive, supporting 27 different programming languages and various different programming frameworks, platforms and frameworks This will ensure that you have visibility to over 70 CWE types — including OWASP Top 10 and SANS 25 — in desktop, web and mobile applications, providing deep visibility into a wide range of vulnerabilities.

Mend SAST provides maximum efficiency and convenience for your developers, allowing them to identify and address vulnerabilities right away, when it’s quickest and easiest to do so. Built-in reports for security standards such as PCI and HIPAA allow you to easily meet compliance requirements. The efficiency and ergonomics of Mend SAST will help your software developers learn to trust their software tools and collaborate more readily with members of the security team.

For more information about Mend SAST, click here.