In the last few years, I have worked with some companies in the market to implement security in their DevOps system, and it was really a good experience that let ...
One of the most confusing systems in the DevSecOps methodology is Dynamic application security testing (DAST). Many people I’ve met think are basically confused between DAST penetration testing and either a DAST tool can be part of the DevSecOps or not.
Therefore, in this blog post, I am going to respond to all these questions while explaining what is a DAST tools, what is its relationship with a penetration test.
What is DAST in DevSecOps?
DAST or dynamic application security testing is a set of vulnerability detection techniques that are used to find flows in an application while running contrary to static analysis. In fact, many types of vulnerabilities could not be discovered by a static code analysis as they only show up when the app is running.
Moreover, many problems related to performance and the time needed to perform a static analysis of complex applications have pushed security experts to find other solutions to find vulnerabilities. In addition, for many years the dynamic application security testing was the most used by security experts due to the very good results it was giving (for example using Fuzzers).
Here is a list of known tools that perform such thing can be used as a DAST tool in DevSecOps:
A Fuzzer is a tool that tries to inject multiple inputs in an application in other to make it crash. This crash is then analyzed by security experts to find vulnerabilities.
DAST analysis could be considered as a gray box penetration test if it is performed bother manually by a security expert and automatically by a dynamic analysis tool.
To understand why a manual test is still necessary for discovering vulnerabilities you should first understand how DAST tools work and what are their limitations.
A DAST tools could be separated in two main categories:
A dataflow based DAST tool analysis the flow of the user inputs to see if they reach sensitive functions in the app. For example, to find an XSS vulnerability, the tool injects some pseudo-random data in the app inputs and tries to see if it is displayed somewhere in the app.
This technique is very efficient and in most cases, it is able to find vulnerabilities. However, with much complex applications, the data flow operation increase exponentially, which in parallel raise the time needed to find a vulnerability. In addition, in some cases, the Dataflow based DAST tool may take even longer than what a penetration tester would take, which makes it inefficient.
Fussing is the act of bombing the application with a bunch of pseudo-random inputs to try to crash it or to try to find an unusual behavior. This technique has shown its efficiency over years and it was the first one to be used by hackers and security experts. However, this technique suffers from a well-known problem called code coverage.
Code coverage is the percentage of code executed by a tool or by a human during the test. The more code is executed the more likely to find vulnerabilities.
In addition to the limitations, I have mentioned above, some types of vulnerabilities like business logic vulnerabilities and architecture-based vulnerabilities cannot be discovered by any tool for now.
DAST techniques and tools must be part of the DevSecOps environment for many reasons:
Therefore, the DAST and the SAST tools are complementary tools in the process of vulnerability detection, we cannot use one without the other. In addition, until now there is no way to eliminate the role of a professional penetration test.
In my opinion, both SAST and DAST tools should be used in the DevSecOps environment, however, they should be supervised and used by a professional penetration tester to only accelerate his job. You should know that both types of tools SAST and DAST generate a lot of false positives that should be analyzed and eliminated by a security expert.
In fact, the most important job of the penetration tester or the security expert in a DevSecOps environment is to qualify and priorities the vulnerabilities. The qualification of the vulnerabilities consists of determining the impact of successful exploitation of that vulnerability on the business. This task cannot be performed by any DAST tool in the market no matter how powerful it is.
Each one of the SAST, DAST, and pentesting has limitations that can be covered by the others. Therefore, combining the SAST, DAST, and the skills of competent penetration testing is necessary for a DevSecOps environment for optimum security.
What I need you to keep in mind is that in a DevSecOps environment, these three components SAST, DAST, and Pentesting are not the only required security component in the system. For example, Software Composition Analysis (SCA) tools are necessary to identify vulnerabilities in the used libraries and plugins.
An OS vulnerabilities scanner is also necessary for this process to ensure that the server OS is not vulnerable to some known vulnerabilities before publishing the app.
Written by: Z. Oualid
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).
todayNovember 1, 2022
Blockchain technology was indeed built with security in mind. This means that it is supposed to be very secure compared to other technologies. However, Blockchain technology suffers from some weaknesses [...]