SAST vs. DAST vs. IAST: Everything you always wanted to know but were afraid to AST

Cybersecurity acronyms can get confusing, especially when they all end in AST. The big three in application security testing are DAST, IAST, and SAST, representing a whole spectrum of testing methods – from looking only at a running application to looking only at source code. Let’s cut through the jargon to see how each type of AST operates, what they can and can’t do, and how they fit into modern DevSecOps and web application security programs.

Dynamic application security testing: Are you vulnerable to attack?

When you are probing an entire running application, API, or web environment and checking for insecure behaviors, that’s dynamic application security testing (DAST). Also known as black-box testing because you can’t see inside the application, DAST can be performed manually (penetration testing) or automatically (vulnerability scanning). When people talk about “DAST tools,” they usually mean automated scanners as opposed to manual security testing tools, though penetration testers also commonly use scanners as part of their toolkit.

DAST tools work by simulating the actions of humans, bots, and external systems that interact with your websites and applications. Modern vulnerability scanners have a built-in web browser to load pages, execute tests, and watch for reactions that indicate a vulnerability. Because they are designed for automated and autonomous testing, they need to support authentication, CSRF tokens, and other mechanisms required to access and test web pages and API endpoints.

Of all the approaches to application security testing, DAST is by far the easiest to get started with – at its most basic, you just enter a URL and hit Scan (though correct initial setup and individual fine-tuning are important to get accurate results). DAST is also the most versatile, as a good quality solution can cover both information security (to scan your own organization) and application security (to scan any web applications you build).

Example: Finding SQL injection with DAST

When a vulnerability scanner reports an SQL injection vulnerability, that means it has successfully tricked the application into executing some database commands. The scanner will typically report the page or endpoint where injection is possible, along with the parameter that was attacked. Scanners with automated confirmation, such as Invicti Enterprise, can also extract and deliver proof of the injection – usually the result of a unique operation executed by the database.

DAST pros:

• Identifies exploitable security vulnerabilities, misconfigurations, invalid security headers, and other issues that are only detectable at runtime
• Technology-agnostic, allowing apps and APIs to be tested regardless of the underlying frameworks and programming languages
• Doesn’t need the source code, so it can test all running components regardless of origin (including dynamic dependencies)

DAST cons:

• Requires a running application for testing (even if it’s only a minimal prototype)
• Testing only covers code that is running during the test
• Reported issue locations may be less precise than with other methods

How Invicti does DAST

Invicti is a DAST tool vendor providing a DAST-based AppSec platform that also incorporates asset discovery with optional IAST and dynamic SCA. Invicti Enterprise builds on well over a decade of experience to address many typical DAST shortcomings, notably using proof-based scanning to maximize confidence in vulnerability reports, providing accurate issue locations (often down to the line of code, when combined with Invicti IAST), and integrating deeply into development workflows to shift dynamic security testing left in the pipeline.

Static application security testing: Show me your code

Analyzing application source code for potentially insecure constructs and data flows is static application security testing (SAST), also called white-box testing because you see the inside of the application. Static analysis is the most common security testing method used during development and the only method usable before you have a prototype running (i.e. in early stages or when working on isolated components).

There are many different types of SAST tools, from simple IDE (integrated development environment) plug-ins to warn about insecure syntax to standalone code analyzers that examine entire repositories and simulate data flows. Because they analyze source code, SAST tools are programming language-specific, and testing a multi-language codebase often requires multiple tools.

Since they are only looking at the code and cannot know the developer’s intent or how the code will be used, SAST tools tend to show warnings and recommendations rather than hard-and-fast vulnerability reports. While this is generally an accepted shortcoming, it can lead to developers ignoring or disabling whole classes of warnings that are usually false positives. This creates the risk of legitimate vulnerabilities occasionally slipping through and also makes SAST results challenging to fine-tune for automated processing.

Example: Finding SQL injection with SAST

When a SAST tool reports an SQL injection vulnerability, it is warning you about potentially insecure inputs when building a database query. In other words, the tool finds code that generates an SQL query, identifies its inputs, and notices that the input data isn’t being processed securely, e.g. by encoding, escaping, or just using parameterized queries. This warns you about potentially insecure syntax but doesn’t guarantee that the resulting application would indeed be vulnerable.

SAST pros:

• Checks static code without needing a running application
• Easy to plug into IDEs and other tools in the development process
• Can check your entire codebase, even code that’s not currently used

SAST cons:

• Can’t find dynamic vulnerabilities, misconfigurations, or any other runtime issues
• Prone to false alarms because it can’t check exploitability
• You can only test code that you have and are actively developing and maintaining
• Needs separate SAST tools for different programming languages

Software composition analysis (SCA): Like SAST, only bigger

SCA is another approach to security testing that works on the code level. Unlike SAST, SCA doesn’t check what the code does but what it’s made of, with most SCA tools focused on identifying and reporting open-source components with known vulnerabilities. Some tools will also check whether smaller pieces of open-source code are used in the codebase.

Interactive application security testing: Between application behavior and code

When a security tool can look inside a running application during testing, you are doing interactive application security testing (IAST). You may also see IAST touted as gray-box testing (as a mix of black- and white-box testing). While it’s more of a catch-all category for everything between SAST and DAST, IAST tools generally aim to either add dynamic insights to code analysis or add code-level insights to dynamic testing. In both cases, the appeal of IAST is to address some of the shortcomings of the two main testing methods.

IAST tools vary widely, from plug-ins through server-side agents to standalone code analysis solutions. Some of these require code instrumentation, where application source code is modified by inserting tracking commands that send runtime information to the IAST tool. Compared to SAST alone, IAST can also catch some dynamic security issues and verify exploitability. Compared to DAST alone, IAST can better pinpoint issues in application code and show why an attack is possible.

Note that the “interactive” part of IAST can be a misnomer since few IAST tools truly interact with the application. See How Invicti does IAST below for a quick summary of Invicti’s true IAST approach. The pros and cons of IAST are similar to those of the “parent” testing method for a specific tool, but the main drawback of standalone IAST is limited code coverage.

Example: Finding SQL injection with IAST

For a DAST-activated, truly interactive tool like Invicti’s IAST, an SQL injection report might have all the information from the DAST scanner plus server-side insights. So on top of the specific page, parameter, and (for Invicti) extracted data as proof of exploit, you may also get the specific line of code to fix and additional proof showing how the test payload (i.e. the injected query) was accepted and processed by the application.

How Invicti does IAST

Invicti’s take on IAST is slightly different, as the IAST component has been very deliberately built as an extension and enhancement to the core DAST scanner. For this true interactive AST approach, an additional IAST agent is installed on the web server or application server, with no code instrumentation needed. The agent works in tandem with the vulnerability scanner to provide runtime insights and server-side information that DAST alone can’t see, like unlinked files that a crawler won’t find, as well as dynamic SCA. Supported server-side technologies for IAST currently include PHP, Java, .NET, and Node.js.

Runtime application self-protection (RASP): Like IAST, only for protection

If you extend the IAST concept a bit, you get RASP. An IAST tool monitors application execution during testing and reports security issues. A RASP tool does almost the same thing, except it runs all the time in production and instead of checking up on test results, it monitors real traffic and operations to detect attack attempts and try to stop them.

Which AST is best?

Ok, that’s a clickbait question – while asking about better or worse makes sense for specific products, each testing method has its pros and cons in specific contexts. Any well-rounded application security program should incorporate several types of security testing to catch as many vulnerabilities as possible and as early as possible in the development process. Ideally, you need at least DAST to cover your own application environment and run dynamic security testing in the SDLC, SAST to catch code-level issues before they can make it into your builds, and SCA to make sure your dependencies are not outdated or vulnerable.

Making security testing work in agile DevOps processes requires deep integration into the CI/CD pipeline and existing workflows in the software development lifecycle (SDLC). To keep up with agile development, security testing needs to be reliable and automated to the point where security issues are found, tracked, and resolved like any other software bug. With DAST in particular, very few existing solutions can achieve the level of accuracy, automation, and remediation guidance needed to move in lockstep with development and operations in a DevSecOps environment.

But if you asked which AST is the most versatile or which is foundational if you could only pick one to start with, that’s easy – you want DAST. To learn how Invicti specifically is extending its core DAST functionality using IAST, read our full white paper Changing the DAST Game with Invicti IAST.