Static Application Security Testing (SAST) is a mature and widely used application security testing approach. It helps developers build secure, high-quality software that can better withstand the types of attacks that have become increasingly common in recent years.
At the same time, SAST has one major challenge: it can generate many false positives, forcing engineering teams to spend time investigating issues that are not real vulnerabilities.
This article examines SAST and the false positive problem. It also explains how false positives can be reduced and how Mend SAST supports this process.
What is SAST?
SAST is an application testing method that analyzes source code to identify possible design weaknesses. It uses static program analysis to detect vulnerabilities without running the application code. This approach is also known as white box testing. SAST works together with other secure coding practices, including source code analysis and source code review tools. Together, these methods give developers several layers of protection when searching for vulnerabilities.
SAST is one of several methods used in application security testing (AST). Other major AST approaches include Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and Software Composition Analysis (SCA).
In an ideal development process, SAST is used early in the software development life cycle (SDLC). This shift-left approach allows developers to remediate issues quickly. It also helps avoid broken builds and prevents defects from moving into later development stages, where fixing them becomes more expensive.
One advantage of SAST compared with DAST or IAST is that it can identify flaws across the entire codebase. For instance, weak encryption may not be detectable by a DAST or IAST tool. A SAST tool, however, can detect this type of issue more easily.
The challenge of SAST false positives
Despite its advantages, SAST has gained a reputation for producing many false positive alerts. These are warnings about possible code flaws that, after closer review, turn out not to be real issues. Two common examples show how this problem can appear in practice.
The first example is project-specific sanitizers.
These are measures used to “clean” data so that a vulnerability cannot be exploited. The following code shows a project-specific 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 an external source. This type of data is often called “taint” or “tainted data.” It can be controlled by a threat actor and may lead to SQL injection.
When tainted data reaches a point in the code where it can cause damage, that location is called a taint sink. In the code snippet above, the executeQuery method is a taint sink for SQL injection. If no additional protection is applied, a harmful string could be passed through userInput and used to attack the database. This could lead to actions such as deleting all users, obtaining administrator privileges, or triggering other malicious activity.
In general, SAST tools check whether a path to the taint sink exists.
This path is known as a taint flow. If such a flow is found, the tool reports a vulnerability. Understanding this mechanism is also useful when comparing SAST and SCA. SAST examines custom code directly, while SCA focuses on third-party and open source components. However, if protections are applied along the flow so that only harmless data can reach the sink, no vulnerability exists. These protections are called taint sanitizers because they “clean” tainted data. As a result, a harmful string cannot reach the executeQuery call.
A sanitizer is often a common library function. Such functions can usually be detected out of the box if the tool vendor knows the library and has already created a suitable rule. A sanitizer may also be custom-built or specific to a particular project. In this case, allowedColumns.contains(userInput) acts as the project-specific sanitizer. It checks that userInput matches one of the approved strings.
In most cases, the best way to prevent SQL injection is to use a prepared statement. This example does not use one, so static analysis tools are likely to report a vulnerability. In reality, this result is a false positive. The input is protected by a project-specific sanitizer that uses whitelisting and allows only expected strings. This is something a static analysis tool cannot know in advance.
The second example is a context-specific vulnerability.
A security tool cannot always determine whether a piece of software is sensitive enough to require authentication and authorization. For this reason, many tools report every case of unauthenticated access. This can create false positive alerts when unauthenticated access applies to harmless software. For example, unauthenticated access to software that only provides time-of-day lookup is probably not a real vulnerability.
Effects of SAST false positives
To understand false positives, it is important to understand the full range of results that a SAST tool can produce. Security testing usually generates the following outcomes:
- True Negative — correctly indicates that a vulnerability is not present.
- True Positive — correctly indicates that a vulnerability is present.
- False Negative — fails to indicate that a vulnerability is present, even though it actually exists.
- False Positive — incorrectly indicates that a vulnerability is present, even though it does not actually exist.
The goal of any AST tool is to maximize true negatives and true positives while minimizing false negatives and false positives. From an engineering perspective, this is difficult to achieve. In practice, many SAST products have been designed to maximize the number of true positives, even if this also increases the number of false positives. This can lead to significant time loss as developers investigate flaws that do not actually exist. Several problems can result from this situation.
Common causes of false positives
There are two main causes of false alarms in SAST testing.
#1 Excessive assumptions in scanners
Some SAST tools rely on too many assumptions in order to support multiple programming languages. In many cases, these assumptions are generic and cannot accurately apply to every language.
When such tools cannot interpret a piece of source code correctly, or when a dependency is missing, they may assume that the code contains a problem. As a result, these static analysis tools can generate a large number of false positives.
#2 Poorly designed rules
Some traditional SAST tools use poorly designed rules and cannot identify vulnerabilities with enough confidence. To compensate, they may flag a vulnerability when there is only a small indication of a possible issue. This is done as a cautious approach, but it increases noise.
For example, some SAST tools look for specific words in string variable names to decide whether those variables contain sensitive data. These words may include authentication credentials, keys, or passwords.
Consider the following code:
userPasswordLabel.Text = “Please enter your password”;Although the variable name includes the word “password”, this does not necessarily mean that it stores sensitive information. It is only a label. If a SAST tool cannot perform deeper analysis to determine whether the variable exposes sensitive data, it may quickly produce a false alert.
How to avoid SAST false positives
Several practices can help reduce false positives and prevent them from weakening shift-left security strategies.
#1 Choose a strong tool
A well-designed static analysis tool is essential. Selecting a tool without properly evaluating its effectiveness can result in wasted time spent reviewing false positives instead of fixing real risks.
An effective tool should provide deep, accurate, and comprehensive analysis for the programming languages used by the organization. It should also cover a broad range of vulnerabilities. A generic tool that is not tuned for the relevant language may produce many unnecessary false positives.
The tool should also integrate smoothly with the existing DevOps environment and CI/CD pipeline. This removes the need to configure or trigger scans separately, which can help reduce noise in SAST results.
A separate guide can provide more detail on selecting the right SAST solution for an organization.
#2 Use customization
Custom rule sets can help reduce the number of false positives produced by a SAST tool. Default tool settings may not match the specific needs of every organization.
When a SAST tool is configured according to internal requirements, it can detect more relevant issues and reduce false positives. Deploying a tool without customization may generate a large amount of low-value output. This noise can make real software security issues harder to identify.
#3 Filter and prioritize
Results that are not important to the security of the software can also be filtered out. For example, findings from “dead code” or packages that are not invoked may be ignored.
Prioritizing test results according to organizational risk is also useful. Results can be ranked by threat severity, vulnerability status, and the ability to remediate the issue. This allows teams to focus on the most critical findings instead of spending effort on issues with little or no impact.
How Mend SAST helps
Mend SAST enables enterprise application developers to create new applications quickly without compromising security. It helps reduce the risks and inefficiencies commonly associated with large alert volumes. This can be achieved quickly because Mend SAST includes an advanced scanning engine that delivers results 10 times faster than traditional SAST solutions. As a result, developers are not left waiting for scan results.
Mend SAST integrates with existing DevOps environments and CI/CD pipelines. Developers do not need to configure or trigger scans separately. The solution is also comprehensive, supporting more than 30 programming languages, along with multiple programming frameworks and platforms. This provides visibility into more than 70 CWE types, including OWASP Top 10 and SANS 25. It also supports desktop, web, and mobile applications, giving teams deep visibility into a broad range of vulnerabilities.
Mend SAST is designed to provide efficiency and convenience for developers. It helps them identify and address vulnerabilities immediately, at the stage when remediation is fastest and easiest. Built-in reports for security standards such as PCI and HIPAA also support compliance requirements. The efficiency and usability of Mend SAST can help developers build trust in their security tools and collaborate more effectively with security teams.
