3 Phases of SAST: When and Why to Use SAST at Different Points in the SDLC

Static application security testing (SAST), also known as static analysis, is a common security testing method that can be performed in three distinct ways: on the developer’s desktop as they write code; as a step in an automated build process; or by simply pointing a tool at the desired source code project files. Each technique has advantages and limitations, and all three can be used in concert as part of a comprehensive secure SDLC. This article will explain the nuances of SAST techniques and explore how to get the most out of your SAST tool based on your needs and use cases.

Today, almost every company has become a software or tech company, whether they’re prepared for it from a cybersecurity standpoint or not. While software sales may not be a source of revenue for every organization, it’s likely that software is a key business enabler in all organizations.

Companies often rush to bring applications to market to stay competitive. They build consumer-facing websites and mobile applications to engage with customers and partners in a variety of ways. But if security vulnerabilities aren’t eradicated from these applications, they may expose sensitive customer and business data, which could severely damage or cripple the business.

While most organizations spend significantly more on network security than application security, more than 80 percent of cyberattacks target the application layer. For this often-overlooked reason, securing the application itself is imperative to securing the organization’s business data and, ultimately, its reputation.

Considering that most cyberattacks target software vulnerabilities within the application layer, a comprehensive analysis of application code is essential to ensuring both its quality and security. This is what static application security testing (SAST) tools provide.

At a high level, there are three phases of the software development life cycle (SDLC) where SAST lowers the security risks in the application.

• During development, engineers designing and writing the application incorporate SAST scans into their development workflow and tooling.
• After development and before production deployment, security teams use SAST tools to scan applications for security vulnerabilities.
• The process of releasing applications into production takes the application through the DevOps machinery, leading to production deployment. This phase also involves SAST to ensure that vulnerabilities are detected before going into production.

Let’s look at each phase in more detail.

The design and development phase is one of the most influential parts of the SDLC in terms of fundamental security activities. SAST tools, which offer the most value during the development phase, analyze application code to identify security vulnerabilities and software quality issues (a.k.a. implementation bugs). This takes place in two ways: analysis of software builds and analysis on the desktop as developers write code. These techniques are complementary, ensuring issues are flagged and fixed as the code is developed.

Build Integration

Build integration, as its name implies, integrates the SAST tool into the software build system. This provides the most comprehensive picture of the code, its dependencies, the build configuration, and other environmental factors. With this comprehensive picture, SAST identifies cross-module factors such as tainted data flow analysis, SQL or command injection, hardcoded credentials, and a host of other issues.

Desktop Analysis

Desktop analysis, relying on a baseline build and its scan results, incrementally analyzes the developer’s changes during a local build. This correlation between the two scan methods gives developers the best opportunity to produce applications that have already been fixed of known bugs and vulnerabilities. Applications come out of the development phase as robust and bug-free as the design and development practices enable.

Analysis Without Build

Beyond development, most enterprises employ security teams that are responsible for tracking security risk across the organization’s IT assets, network, and application portfolio. Security teams are also usually responsible for compliance policies the organization must meet. To assess the security landscape, these teams need to scan applications and track vulnerabilities independently. Unlike developers, security teams are not software engineers and are, therefore, not able to work directly with build systems. Their mission is simple: track vulnerabilities. Thus, they need a way to run SAST on applications. The solution is analysis without build — in other words, scanning source code directly (without first having to conduct a full build operation) to identify vulnerabilities. This method allows security teams to gather vulnerability information independently by simply pointing to a project’s source repository (on a local SCM system or on Git). Analysis without build is ideal for languages like Java, JavaScript, and C# that are interpretive or where the code can be modeled fairly accurately without requiring compilation.

Conclusion

Now that we’ve examined the three ways in which SAST can be used to produce secure applications before deployment, note that each has its own purpose and sweet spot. Build integration is unmatched in its ability to have a comprehensive picture from the build. Desktop analysis is extremely convenient and unobtrusive for developers to use as they code, enabling them to produce their best code before checking it in. And analysis without build is valuable for security teams (language permitting) to assess the vulnerability and risk profile of an application. Together, these methods help businesses in all industries develop and deploy applications that are inherently more secure.