Home » Security Bloggers Network » Static Application Security Testing: SAST Basics

Static Application Security Testing: SAST Basics

by Ayala Goldstein on June 18, 2020

Static Application Security Testing (SAST) has been a central part of application security efforts for the past 15 years. Considering Forrester’s recent State Of Application Security Report, 2020 prediction that application vulnerabilities will continue to be the most common external attack method, it’s safe to say that SAST will be in use for the foreseeable future.

According to the Forrester report, a survey of security professionals showed that the majority of external attacks in 2019 were carried out either by exploiting a software vulnerability (42%) or through a web application (35%). SAST has become synonymous with application security testing tools, but if we really want to ensure our software products are secured it’s important to know how the tools we use work and how to maximize their value.

Like any technology, especially when it comes to security, SAST has its pros and cons. It enables organizations to detect potential vulnerabilities, but can also slow down development. That’s why it’s important to understand how SAST works, its strengths and weaknesses, and how it can be improved.

Sponsorships Available

What Is SAST?

Static application security testing (SAST), one of the most mature application security testing methods in use, is white-box testing, where source code is analyzed from the inside out while components are at rest. Gartner’s definition of SAST is “ a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities.”

How Does SAST Work?

As its name implies, SAST scans static code and tests code at rest, without having to run it. SAST is usually implemented at the coding and testing stages of development, integrating into CI servers and, more recently, into IDEs. SAST scans organizations’ in-house code and design to detect flaws that are indicative of weaknesses that could lead to security vulnerabilities.

SAST scans are based on a set of predetermined rules that define the coding errors in the source code that need to be addressed and assessed. SAST scans can be designed to identify some of the most common security vulnerabilities out there, like SQL injection, input validation, stack buffer overflows, and more.

SAST Pros and Cons

Let’s start with the good news. SAST is a top application security tool and, when done right, is essential to organizations’ AppSec strategy. Integrating SAST into the SDLC can help improve your organization’s security profile. Here are the top benefits of Static Application Security Testing.

Pros

#1 Shifting security left

Integrating security testing into the earliest stages of software development is an important practice. SAST helps shift security testing left, detecting vulnerabilities in proprietary code in the design stage when they are relatively easy to resolve. Finding and remediating security issues at this stage saves organizations the costly efforts of addressing them closer to the release date or, even worse, after release.

#2 Ensuring secure coding

SAST easily detects flaws that are a result of fairly simple coding errors, helping development teams make sure that they comply with secure coding standards and best practices.

GET GARTNER’S FIRST REPORT ABOUT SOFTWARE COMPOSITION ANALYSISDownload

#3 Detection of common vulnerabilities

Automated SAST tools can easily detect common security vulnerabilities like buffer overflows, SQL Injection, cross-site scripting, and more with high confidence.

Cons

Unfortunately, although SAST is a very mature technology which has been in use for the past 15 years, it still has its disadvantages. Here are some of the main weak points in SAST:

#1 Doesn’t cover all vulnerabilities

Issues like authentication, access control, and cryptography are hard to detect automatically in pre-production source code. Obviously, SAST also can’t cover run-time issues or configuration issues, requiring organizations to implement additional security testing tools.

SAST also doesn’t cover open source vulnerabilities. Since today’s applications are comprised of 60%-80% open source components, this leaves a substantial part of the code un-tested, requiring SCA tools.

#2 High number of false positives

SAST results include a high number of false positives, costing development and security teams a lot of time and effort weeding out the false alarms in search of the real issues. Considering the competitive pace of development and the amount of time it takes to remediate critical issues, dealing with the noise of false positives puts quite a strain on development.

#3 Time consuming

Although automated SAST can scan continuously, one scan can take several hours for a large codebase. In addition, once the results are provided, they require analysis. SAST can only point out potential vulnerabilities, leaving it up to developers to verify that a suspected weakness is really a security risk.

SAST Pros and Cons

How to Choose the Right SAST Tool for Your Organization

The AST market is full of SAST offerings, often bundled up with additional solutions, making it a challenge to find the right fit for your organization.

OWASP’s list of criteria for selecting the right SAST tools can help companies narrow down the options and choose the solution that best helps them improve their AppSec strategies:

Language support: A top consideration is which languages your organization uses. Make sure the SAST tool that you use offers you complete coverage for those languages.

Vulnerabilities coverage: Make sure that your SAST tool covers at least all of OWASP's Top Ten web application security vulnerabilities.

Accuracy: While accuracy is a weak point for SAST and there will always be false positives and false negatives, it’s important to check the accuracy of the SAST tools that your organization is considering.

Compatibility: Like any automated tool, it’s important that the SAST tool you use is supported by the frameworks you are already using so that it integrates easily into your SDLC.

IDE integration: A SAST tool that can be integrated into your IDE will save you valuable remediation resources.

Easy integration: Find the SAST tool that is easy to set up and integrates as seamlessly as possible with the rest of the tools in your DevOps pipeline.

Scalability: Make sure the SAST tool you integrate today can be scaled to support more developers and projects tomorrow. A SAST tool can seem to scan quickly on a small sample project; make sure it delivers similar results on larger projects.

Rising scale can also impact the cost of the solution. OWASP’s list points out that it’s important to consider whether the cost varies per user, per organization, per application, or per line of code analyzed.

SAST: An Important Component in Your Application Security Journey

Ensuring security in application development usually requires a value tradeoff. This also applies to SAST. It offers high value when it comes to coverage and visibility over an organization’s static codebase. It also integrates early in the SDLC, enabling organizations to shift security left.

Unfortunately, the high number of false positives and the need to further analyze SAST results are both major barriers to agility. Software development teams today are faced with a number of challenges. As software development cycles become shorter and shorter, the risk of attacks to the application layer continuously rises, and development teams struggle to combine security and speed.

Integrating SAST demands organizations strive to find the right balance between covering all security vulnerabilities and minimizing risk, and delivering quality products at a competitive speed.