DAST in DevSecOps

In my previous article I had mentioned the positives and the limitations of performing Static Application Security Testing (SAST). You can have a look at it here - https://www.garudax.id/posts/sourav-mallick-1a482980_sast-in-devsecops-application-security-testing-activity-6997810740204113920-DnV0?utm_source=share&utm_medium=member_desktop

DAST (Dynamic Application Security Testing), a part of black box testing, is designed to identify vulnerabilities by interacting with the running application. This helps in identifying both the compile-time and the run-time vulnerabilities that are only detectable within a running application. It does not require access to the application’s original source code as it only scans through execution of application. Hence the limitation of language dependency (which is there in case of SAST) is negated. The test is executed in runtime and thus security vulnerabilities are detected there itself, quickly and frequently.

The main advantages of DAST are:

• Low false positives – As the source code is not scanned, it has lower chances of giving false positive results. In DAST, the actual application is run and hence it can tell whether a particular vulnerability actually exists.
• No language dependency – In case different programming languages are used, DAST is the go-to option as it can run on any language for any environment.
• Identification of runtime vulnerabilities / configuration issues – Since DAST is performed on running applications, the runtime vulnerabilities or configuration issues can be captured.
• Since the scanning takes place dynamically, the issue of obsolete static reports never arises.

However, with advantages there are limitations as well, such as:

• It finds vulnerability near the end of CI/CD pipeline. Hence it may be more expensive and time-consuming to mitigate the threat(s).
• As DAST does not have access to the source code. Hence it will be able to report the presence of a particular vulnerability but will not be able to point the exact line of code where the vulnerability is located.
• DAST requires a running application. DAST solutions require the application to be complete enough to execute.

Since both SAST and DAST have their own pros and cons, it is advised to use both of these testing methodologies together in a CI/CD pipeline, as both of them complement each other effectively.

When incorporating DAST into a DevSecOps pipeline both people and process aspects play crucial roles. The people aspect includes Developers, Security Engineers, Quality Assurance Engineers, Operations Team as well as Management and Leadership. In the context of DAST in a DevSecOps pipeline, the involvement of people with specific skills and responsibilities becomes instrumental in incorporating security testing into development and deployment processes. The people aspect in a DevOps pipeline is about fostering a collaborative and cross-functional mindset where people with different skills and expertise work together to achieve shared goals, including integration of security practices such as DAST.

The process aspect, on the other hand, involves defining and implementing a set of structured steps and practices to ensure the effective integration of security testing into the development and deployment phases. These include requirement gathering, the appropriate tool selection, the integration into the CI/CD pipeline, test execution and configuration, result analysis, continuous improvement, etc.. These process aspects ensure that DAST is seamlessly integrated into the DevSecOps pipeline, the vulnerabilities are identified and addressed effectively, and the overall security is continuously improved.

Thus, both the people and process aspects need to be aligned and work in tandem to ensure the successful integration of DAST into the DevSecOps pipeline.

However, practicing DAST in DevSecOps can present some challenges. They include:

• Choosing the appropriate tool – Selecting the tool that aligns with the technology stack and integrates well with the DevSecOps pipeline can be a bit challenging. Factors such as compatibility, scalability, ease of integration, etc. must be carefully evaluated.
• Expertise and skill gap – DAST testing requires expertise in security and the ability to interpret scan results accurately.
• Continuous Testing – Implementing continuous testing practices with DAST can be challenging as the application evolves. Ensuring that new features are adequately tested for security vulnerabilities in an ongoing manner can require dedicated effort and automated processes.

Addressing these challenges requires a combination of technical solutions, process refinement and collaboration among teams. Organizations should thus continuously adapt and improve their DAST practices to mitigate these challenges effectively.

**Disclaimer: To know more you can DM me. All opinions expressed in the article is solely the opinion of the author and in no way whatsoever related to the organization in which the author works for.