Can DAST make it in today’s development environment?
DAST, dynamic application security testing, is mostly used by specialized testers, since it needs an ample amount of time. How does it fit into a development environment that depends on speed? Is there any way to “bridge the gap” and to build on DAST’s strengths to ensure that teams can use it effectively even in the modern DevOps environment?
DAST (dynamic application security testing) has long been the go-to security testing technology, but remains mostly in the hands of specialized testers with the time and expertise to use it. With DAST, teams can essentially put themselves in the hacker’s seat, using the same techniques a hacker would to test applications, probing for vulnerabilities. DAST does a thorough job, but needs time – and in a modern release environment where applications and their components are constantly being updated, that time may not always be available.
Is there any way to “bridge the gap” and to build on DAST’s strengths to ensure that teams can use it effectively even in the modern DevOps environment? In fact, new approaches to DAST have yielded systems that significantly speed up the testing process, allowing for the convenience of speed and thoroughness of true dynamic testing.
DAST is a black-box testing technology that automates/mimics a pen tester. Unlike SAST (static application security testing), it does not require access to the source code. It tests the applications over HTTP requests and by examining the client-side rendering of the application, much like a pen-tester would.
The results of the scan are pretty compelling. DAST scans provide high-fidelity results, including actual traffic that can exploit the found vulnerabilities. If an issue is reported and is – in all probability – real, then it should be remediated ASAP. That thoroughness comes at a price though. DAST can take a long time to complete its scans, running for many hours and even days on complicated apps. With shortening release cycles enabled by automation, it is increasingly harder to find time to run full DAST scans on any continuous basis. The era of long release cycles that provided time to also run a DAST scan is over. Continuous, incremental releases happening weekly, daily, or even hourly is the new norm.
So how does DAST fit into this development environment? By adapting its thoroughness to an environment where speed is essential. By breaking down the scan process into components that can check segments of applications separately, developers can use DAST to test for security issues during development without losing time. After development is complete, a thorough, full-throttle DAST scan will ensure that the product is ready from a security perspective.
One way to do this is to design DAST scan systems that only examine changes in the application. Until now, scans were conducted on applications as a whole, but new developments in technology enable the DAST scanner to automatically identify those parts of the app that changed relative to the last scan, and scan only those. This is known as “incremental scanning” and can significantly shorten scan duration.
DAST systems are also being redeployed to test for specific issues. Generally, DAST scans apply a comprehensive battery of tests that cover all possible techniques hackers can use. To make things more efficient, systems are now aiming to find only the high-value issues that hackers are most likely to take advantage of.
Yet another DAST development that can accommodate the system to the modern development environment entails scaling out the app being tested. To test properly, DAST engines need to make a large number of malicious requests of an app, but cannot make too many at one time, lest a DOS (denial of service) situation result. That’s another reason DAST is considered slow, but new technologies that enable apps to quickly scale out, like Kubernetes, might open up new options to run DAST scans more quickly.
DAST is an important tool in security testing, with certain unique capabilities available only to it by virtue of its nature. Giving up on it would be a great disservice to teams who will miss vulnerabilities that only DAST can find, and miss the actual sample exploits they can use to debug and fix code. With new, innovative approaches, DAST can fit right into the modern development environment, and ensure that the software and services we rely on are safe and secure.