What is static application security testing (SAST)?

Gartner defines SAST as:

Static application security testing (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. SAST solutions analyze an application from the “inside out” in a nonrunning state.

As the cost of a data breach continues to rise (the average cost in 2020 was $3.86 million, a 10% rise over five years), organizations constantly seek out ways to improve their software’s cybersecurity. Static Application Security Testing (SAST) scans application source code to identify known and unknown vulnerabilities, including many items in the OWASP Top 10. This shifts security testing from post-deployment penetration tests (“pen tests”) and network-based scanning software to security testing while code is created. A SAST shifts security testing to early stages of development, which helps alert developers of code vulnerabilities before they deploy to production. SAST tools are an essential part of the “Shift Left” testing and security.

The vast majority of developers lack extensive security experience and training and often don’t understand the vulnerabilities introduced by certain coding practices. Many organizations don’t have the budget to hire full-time application security professionals, so they must rely on developers and scanning tools. Unfortunately, false positives and improperly-prioritized alerts from some SAST tools lead to wasted development time and effort as engineers focus on the wrong things.

Discover a new approach to SAST

Apiiro offers more AppSec context and less noise

Book a Demo

What is the Purpose of SAST?

Most organizations understand that their software must be tested for vulnerabilities but they often take an older approach by scanning software after it has been deployed to production. This process can find vulnerabilities but it also leaves the application open to potential attackers who could find vulnerabilities before you do. Even if security scans are performed in a staging environment, any code changes must be rolled back and sent to the development team to remediate and re-deploy. This increases the amount of development re-work, increasing costs and slowing down delivery.

Another common way organizations test for vulnerabilities is using penetration testing and manual code reviews. In these processes, white hat hackers test your applications and code and report on any vulnerabilities that they found and provide a proof of concept to show how an attacker would breach the system. This method is useful, but vulnerabilities can still be missed during manual testing and it only covers a specific scope. For example, hackers would be hired to assess security for a single application or release. Pen tests are also often performed on a periodic basis that is not tied to changes in the code or infrastructure.

Traditional methods of testing for vulnerabilities slow down the development process and leave your organization vulnerable to exploits. Scanning after production deployments might find a vulnerability before an attacker, but it means you must perform an emergency security patch for the software. This could mean downtime for users or waiting for a maintenance window, which provides a period of opportunity for an attacker.

Instead of waiting for vulnerability discovery after code deployment, SAST tools promotes a “shift left” way of thinking about security. Instead of compiling code and deploying it to a staging or production environment for testing, the SAST tool scans the code as it’s created. A SAST tool provides real-time feedback for developers as they type. The real-time feedback is similar to the way development tools such as Visual Studio provide feedback on inaccurate or uncompilable code. Developers can see vulnerabilities in their coding environment with information and decision-making advice so that it can be remediated quickly.

By identifying vulnerabilities while code is being created, developers identify vulnerabilities early in the software development lifecycle (SDLC), reducing risk and re-work while accelerating software delivery.

Figure 1: Testing as part of the DevOps process flow

What Vulnerabilities Can SAST Tools Identify?

One of the most beneficial aspects of a SAST is its ability to automatically and continuously scan code. This can improve results over manual-only reviews that may miss critical risks. Here are a few critical vulnerabilities a SAST tool will find during code development:

Buffer overflows. In some languages, such as C and C++, variables are assigned values with no bounds checking, which means an attacker can send input that will “overflow” the variable’s set amount of byte assignment. The malicious input can overflow memory and overwrite existing code flow with an attacker’s own instructions. For example, an attacker could gain remote code execution on a target server or workstation.

Most web-based languages are secure from buffer overflows, but server applications are often written in more advanced languages such as C. The infamous Heartbleed was an example of a buffer “underflow,” but it’s often considered one of the most critical web-based buffer exploits, with some servers still vulnerable to the affected OpenSSL versions.

SQL injection. Databases are often a target for attackers due to the enormous amount of data stored on production servers. User-generated input should never be trusted and always validated, but many developers mistakenly build SQL queries within code or allow unvalidated input to be passed to a database.

Malformed SQL statements executed on the database server can result in disclosure of sensitive data, denial-of-service from dropped tables, or privilege escalation. For example, in 2014, Tesla was found to be vulnerable to SQL injection where security researchers found that it could be used to gain administrative permissions on the database and steal data.

Cross-site scripting (XSS). XSS is one of the most common web-based application vulnerabilities. There are two types of XSS – reflected and persistent. Reflected can be used to “reflect” scripted actions back at the user, usually from a GET request using URL input. Persistent stores malicious scripting in the application’s database so that it can later be rendered in the user’s browser.

Any JavaScript that can run in the user’s browser can perform actions in your application based on the context of the user. An attacker can use XSS to gain access to user data and cookies with sensitive information or trigger actions on behalf of the user.

These vulnerabilities are high risk and can be critical to the organization’s security posture, but SAST can identify many vulnerabilities that come from insecure code. Instead of waiting days for a manual review, the scans are done within minutes. Many SAST tools are integrated into the development lifecycle so they work in parallel with code creation rather than adding a step to your developer’s current workload.

What Do You Need to Run a SAST Tool?

An effective SAST tool has specific features that make it easier for developers to detect vulnerabilities. In an enterprise environment, these tools need the ability to support multiple developer environments and work with several different repositories. Here are some features to search for when determining the right SAST tool for you and the steps you need to take to integrate it into your environment:

Find a tool that works with your language. Most developers have a language of choice, and this language is used across your environment. The SAST tool must be able to read the language used by your developers. If your developers work with multiple languages and environments, find a tool that supports as many languages and environments as possible.

Use a SAST that helps make business decisions. In most organizations, developers outnumber security staff. Some environments don’t have any security staff at all, which means the SAST tool must help developers understand the importance of risk factors and prioritize vulnerability fixes. For example, most reflective XSS vulnerabilities are considered high risk and should be remediated quickly. This vulnerability should take precedence over a low-risk exploit.

Customize the tool for your business requirements. Whether you’re in a DevOps environment or you need a SAST tool to help developers create more secure code, the tool that you choose should allow for customizations that fit your environment. For any compliance regulations you must follow, the tool must support these specific requirements and check for any code issues.

Scan all applications. A SAST tool shouldn’t stop at just one scan. It should also scan production applications as they execute to check for any missed vulnerabilities. A good tool will continually discover and scan current and new repositories and help you identify vulnerabilities in applications already deployed when it was implemented. After analysis, it should help developers prioritize important vulnerabilities and work with your set policies to prioritize applications by order of importance and productivity.

Few false positives. Analysis of results should be easy to understand for developers, but it should also produce few false positives. A false positive puts unnecessary stress and overhead on developers to remediate, and they can cause more problems than help if your developers are in a persistent state of remediation on incorrect results.

Provide developers with better security training and understanding. Most organizations are under constant pressure to ensure data governance is a priority. This can be a difficult goal if developers do not understand cybersecurity and the risks associated with vulnerable code. SAST should provide guidance and understanding to developers so that they can not only remediate existing issues, but they can also write more secure code in the future.

The Problem with “Legacy” SAST Tools

Legacy SAST tools are overwhelming for the AppSec engineer. After 20 years, they still generate 40-80% false positives. As waterfall methodologies have shifted to agile, on-premises servers have moved to the cloud, and manual handoffs between Development and Operations teams have turned into “DevOps”, SAST hasn’t been able to keep up, constrained by its inherent inability to have a more in-depth and contextual knowledge of the code.

There is little differentiation between traditional SAST scanners. They all scan code, identify potential vulnerabilities like SQL injection or buffer overflows on a snapshot of code, and spit out a series of alerts that overwhelmed and overworked AppSec engineers have to manually investigate. Vendors have only made marginal improvements to reduce false positive rates and they will continue to spin their wheels without embracing a fundamentally new approach.

Discover a new approach to SAST

Apiiro offers more AppSec context and less noise

Book a Demo

A Next-Generation Approach to SAST

Static analysis needs to do four essential things in order to solve modern risks:

1. Analyze application code, Infra-as-Code, and open-source code in one engine and connect all code elements in a unified risk graph.
2. Enrich risk assessments with context by analyzing text from the commit message, pull request discussions, and user stories.
3. Profile developers’ knowledge and skill sets to enrich the risk assessment.
4. Enrich data from 3rd-party sources such as API Gateways and vulnerability scanners to generate more risk-based context and reduce false-positives.

These four fundamental enhancements combine to provide contextual insights that make findings more risk-based and actionable.

Apiiro looks at application security testing using a new lens. Instead of providing vulnerability alerts, Apiiro focuses on risk, which is multidimensional. This is accomplished by understanding code, but going beyond to incorporate new sources of data that can provide AppSec practitioners with deep visibility into their applications – even allowing them to understand the applications better than their developers. On top of that, Apiiro automatically identifies critical risks that could impact the business across the SDLC, from design to code to cloud.