DAST

DAST works by simulating automated attacks on an application, mimicking a malicious attacker. The goal is to find outcomes or results that were not expected and could therefore be used by attackers to compromise an application. Since DAST tools don’t have internal information about the application or the source code, they attack just as an external hacker would—with the same limited knowledge and information about the application.

There are many different types of DAST solutions available. These range from more traditional DAST tools that provide dynamic scanning and analysis of web applications during runtime, to modern DAST solutions that combine web and API scanning, pen testing, and fuzz testing. There are also next-generation technology tools such as interactive application security testing (IAST). 

Static application security testing (SAST) uses the inverse approach to DAST: it looks at an application from the inside out, with full knowledge of the internal workings (source code, binaries, and so on). The goal of this “white box” testing is to identify code issues. During SAST, the application isn’t running, because SAST examines the source code of an application, not how it behaves at runtime. SAST reviews an application’s data and control paths for security weaknesses.

DAST is performed while an app is running, analyzing it as an attacker would and identifying potential vulnerabilities. DAST finds exploitable flaws in a running application. 

SAST is used early in the software development life cycle (SDLC) in modern DevOps models, providing results iteratively, while developers are creating segments of code for an application as part of a continuous integration / continuous deployment (CI/CD) approach. SAST analysis results can identify the exact lines of vulnerable code, making it easy for developers to fix software issues as they are coding.

DAST can be used early in the build integration phase of the SDLC, but it’s typically used in later in the test and production phases. In these later phases, an application has already been built, so it can be analyzed during runtime. DAST can identify potential vulnerabilities but doesn’t identify the lines of vulnerable code like SAST can. 

Interactive application security testing (IAST) is an AppSec method that examines code for vulnerabilities while an application is running, during an automated or manual test run by a developer. IAST, unlike DAST and SAST, works from inside an application; DAST works from the outside and looks at an application from the outside in. SAST looks at the inside of an application by analyzing the source code. IAST actually functions from within an application.

IAST doesn’t require the entire codebase or access to the whole application. IAST only needs the elements of an application that are used during the functional testing. IAST reports in real time and is typically implemented within a Q&A environment, where functional tests can run. 

Runtime application self-protection (RASP) is a type of AppSec solution that runs on a server when an application is running. It’s designed to detect and protect from attacks made on an application in real time. RASP analyzes an application’s behavior to identify attacks and help support immediate attack remediation. When a security activity occurs in an application, the RASP tool takes command of the application and works to mitigate the issue.

Penetration testing (pen testing) simulates cyber attacks against an application in order to identify vulnerabilities. Pen testing is similar to DAST in that both perform activities that uncover potential vulnerabilities, but the difference lies in the testing goals and capabilities. DAST automates identification and reporting of noted vulnerabilities, while pen testing involves physical attempts by a human tester (using pen testing tools and/or DAST tools) to exploit a discovered vulnerability and determine whether it’s truly a viable threat.

A key strength of DAST is that it identifies runtime issues—weaknesses that aren’t discoverable when an application isn’t running. Additionally, DAST looks at how an application actually responds to an attack, providing helpful insight into how likely it would be for that vulnerability to be manipulated.

SAST is great at identifying vulnerabilities while code is being written; without SAST, a development team might not discover issues until later in the SDLC. SAST also helps find the exact location of coding issues, making it easy for developers to pinpoint and fix the vulnerability.

IAST enables DevSecOps and supports continuous testing, monitoring, assessment, and validation in real time. IAST helps prioritize and alert on key critical risks, as defined by business goals and application security needs. It also leverages the existing tests that are done during the testing phase and can actively verify whether an identified vulnerability is exploitable, which reduces false positives. IAST solutions also identify vulnerable lines of code and provide helpful remediation advice, making it easier for developers to fix security issues in their code.

Using multiple AppSec solutions is an application security best practice. By employing a variety of methods that each involve separate activities and different phases of the SDLC, AppSec experts can be sure that they have the most comprehensive view of their security stance. Since each solution expertly identifies potential vulnerabilities using alternate methods, a combined testing approach offers the most comprehensive application security. To learn more about this modern approach, read the blog post, Which application security tools should you choose? from Synopsys.