SAST vs. DAST: what is the difference and how to combine the two?

No matter how well developers follow the latest secure coding guidelines and no matter how perfect their intentions are, some production code will almost always include at least one security issue. Developers are only human, and when faced with trying to balance the large and growing list of potential software vulnerabilities and the mounting pressures for faster release cycles, something has to give.

As with most other areas of software development, the solution is to use test automation to find the weak points in your source code and overall application security, which bad actors will inevitably find and exploit.

This article looks at static application security testing (SAST) and dynamic security testing (DAST), the basic ideas behind these application security testing approaches, and their advantages and disadvantages. It also explores how to leverage SAST and DAST and combine the two to release secure software and produce truly secure applications.

SAST, DAST e SCA

What Is SAST?

Static application security testing (SAST) is a white-box testing methodology. In software engineering, white-box testing evaluates a range of static inputs, such as documentation (requirements, design, and specifications) and application source code to test for a range of known problems. As a form of automated static testing, a SAST tool scans your source code and related dependencies (frameworks and libraries). During the scan, the tool refers to a predefined set of rules to detect issues and vulnerabilities, marking their exact location. SAST tools are easy to integrate into a CI/CD pipeline. This means the scanning process can be launched as soon as a team member commits code to a source code repository, such as GIT.

There are a number of clear advantages to using SAST over other security analysis approaches:

• No need for a running application in order to provide immediate benefit.

• Detect potential problems from the earliest stages of the development process by integrating SAST into your build system the moment code starts working. Not only is it cheaper and easier to fix vulnerabilities at this point, it also raises developer awareness to potential problems helping them avoid other, related issues.

• Eliminates the need to build even a partially functioning version of your product. This means you don’t have to spend time compiling and deploying code or have to deal with the headaches of configuring your build system—including having the relevant infrastructure and related assets (e.g., security tokens and certificates).

Why Is SAST Important?

While Static Application Security Testing offers many benefits, the most significant is its ability to detect issues and mark their precise location, including the file name and line number. For each detected issue, the SAST tool will indicate its severity and offer a brief description. On the surface, this ability to pinpoint problems may seem trivial, but finding problems is one of the most time-consuming aspects of a developer’s work. Nothing is more frustrating than knowing a problem exists but not being able to pinpoint it, especially when the available information comes from vague stack traces or cryptic compiler error messages. SAST can be used on a wide range of software, it supports a wide variety of high-level languages, and most SAST tools are highly configurable.

What Is DAST?

Dynamic security testing (DAST) uses the opposite approach of SAST. Whereas SAST tools rely on white-box testing, DAST uses a black-box approach that assumes testers have no knowledge of the inner workings of the software being tested, and have to use the available inputs and outputs. Black-box testing needs to be dynamic. This is because as an application runs, the number of inputs and outputs increases and decreases, and the data they consume or release continuously changes. DAST tools therefore require that—at the very least—you have a working version of an app available for testing.

Unlike SAST systems, which are omnivorous when it comes to the types of inputs and can be used to scan nearly any type of software, the scanning and detection methods DAST tools use will depend on the application type. For example, when testing web applications, a DAST system will crawl web pages, locate the end points of web services, and test a range of inputs and outputs. Another key difference between SAST and DAST, is that because DAST requires functioning software, it can only be used much later in the development process than SAST.

Why Is DAST Important?

With its dynamic approach to security testing, DAST can detect a wide range of real work vulnerabilities, including memory leaks, cross-site scripting (XSS) attacks, SQL injection, and authentication and encryption issues. It is capable of detecting all the OWASP Top Ten vulnerabilities. DAST can be used to dynamically check an application’s internal state, based on inputs and outputs, but also to test your application’s external environment. Thus DAST can be used to test any system and API endpoint/web service your application connects to, to test physical infrastructure and host systems (networking, storage, compute), and to test virtual resources such as API endpoints and web services. This makes these tools valuable to developers, but also makes DAST useful to the wider operations and IT community

SAST vs DAST

Now that we’ve explored the benefits of SAST and DAST scanning tools, let’s look at the drawbacks of each to help determine which approach might be right for you.

The Drawbacks of SAST

As noted above, the greatest advantage of SAST is that as a static approach, there is no need for a running application, and you can start using it in the earliest development stages, but this approach has a number of problems:

• Reliance on static inputs: SAST can only find certain types of problems. While these problems are of course important, they can lead to a false sense of security, since many hackers run specific attacks on running software and its supporting infrastructure.

• Limited issue set: These issues relate to areas such as access control, encryption, or memory management. For example, when employing a SAST tool to locate common problems such as buffer overflows caused by C’s printf state, it might detect similar issues in languages that are written in C (e.g., Python).

• Only as good as their rule set: In cases where these rules produce ambiguous results, this can lead to a high number of false positives/negatives. Any false positives/negatives will require human interpretation, which undermines the advantages of using an automated approach.

• Speed: SAST tools were historically very slow whilst scanning, and could bottleneck development whilst scans are in progress. More modern SAST tools like Snyk Code are capable of real time scanning,so developers can find and fix vulnerabilities during development without waiting for scan results. Try our free online code checker toolto see how the Snyk code engine analyses your code for security and quality issues

The Drawbacks of DAST

DAST’s dynamic approach offsets the drawbacks of SAST’s static nature, but it also has its own unique set of problems:

• Requires a runtime environment: This means time and effort must be invested in building the environment, then compiling and building running software. Anyone familiar with building mobile apps for iOS and Android knows that just acquiring the right certificates to deploy an app to a test device is a massive time sink.

• Requires running software: You can only start using DAST toward the end of the development process, when the pressure to ship working code often outweighs the desire to ship secure software.

• Time and cost to remedy issues: The types of errors DAST detects generally take longer to diagnose and are more expensive to fix. This of course makes it of less benefit at the time when it would be most useful.

• Coverage: Like SAST, DAST does not provide 100% coverage and cannot detect static issues in source code or related libraries. Last, it differs from SAST in that it is harder to integrate DAST directly into your CI/CD pipeline.

A Combined Approach for Application Security

When comparing SAST versus DAST, SAST may seem like the better choice overall, since it can be used earlier in the development process when it is easier and cheaper to fix detected security issues. However, relying on one method of detection alone is highly problematic. A combined approach using SAST and DAST scanning tools will enable you to find a wider range of vulnerabilities and exploitable weaknesses and allow you to reap the benefits of both SAST’s static and DAST’s dynamic approach to security testing.

Adding other forms of security testing into the mix, such as interactive application security testing (IAST) and runtime application self-protection (RASP), can further strengthen the security of your applications, though an in-depth discussion of these alternative methodologies is beyond the scope of this article.

Combining your SAST tool with an SCA tool will give you a more holistic view of your application's overall security, covering both proprietary code (SAST) and any vulnerabilities introduced through open source packages (SCA). Using SCA and SAST together can also help you meet compliance with standards such as PCI.

Check out our SAST buyers guide to help you choose the right SAST tool for your organisation.

“Snyk Code gave us a net new capability to add to our arsenal, ... It analyzes code we write, quickly, and provides legitimate, actionable information that engineers can use during development and within build workflows. The Snyk view lets engineers quickly see any code issues, other sources for that issue, as well as how other engineers in the industry have fixed the issue. It gives us meaningful static analysis results that we can take action on immediately.”

Joren McReynolds, Director of Engineering at Panther Labs

Develop fast and stay secure with Snyk’s developer-first tooling and best-in-class security.