In the beginning, there was DAST. From the earliest days of web applications, the tried-and-true (and much maligned) vulnerability scanning technique has been dynamic analysis, which treats software as a “black box” and attempts to exploit it from the outside through a series of automated attacks that reflect real-world threat vectors. Despite the rise of SAST (static, or “white box” analysis of code itself), software composition analysis (SCA) and a myriad of other techniques, DAST has remained the cornerstone of AppSec practice and is often required for regulatory compliance.
However, it is also one of the least friendly forms of security testing to the software developer, as it must be run long after code is written and deployed, and despite a high degree of accuracy, requires developers to spend significant toil to identify the source of the issue and determine remediation steps. Especially in the modern world of DevSecOps and developer-focused security tools, DAST is an outlier in its inability to be integrated with the developer experience.
Must this always be the case? Recent advancements in runtime monitoring, machine learning, and accuracy of other techniques like SAST may offer new possibilities for dynamic testing for the first time in many years.
Join Snyk, the leader in Developer Security, as we discuss ideas for next-generation DAST, including:
- What are the benefits of traditional dynamic analysis and why do most AppSec teams still rely on it despite its limitations?
- What makes DAST so difficult to fit inside a modern DevSecOps workflow?
- What needs to change about DAST for it to provide a positive developer experience?
- Can modern techniques like eBPF potentially enhance the value of DAST results for developers?
- Is there a possibility of true DAST-to-SAST correlation on the horizon? What would this mean for the future of AppSec practice?