DAST Automation: Your Team's Future Hacker-in-a-Box

You've probably heard all about the new and not-so-new technologies in the application security testing space DAST, SAST, RASP, IAST, fuzzing, and SCA. Probably the oldest technology in this alphabet soup is DAST or Dynamic Analysis Security Testing. DAST works like a "hacker-in-a-box" testing live web applications and web services. It has been around since the mid-1990s.

DAST is naturally focused on finding high-risk issues, performs "end-to-end" testing of each piece of functionality across all layers of an application, and provides a handy proof-of-exploit, making issues much easier to validate and demonstrate than other technologies, like SAST (code scanning). And, while DAST roamed the Internet before Google existed and is ubiquitous in pen-testers' arsenals today, it always struggled to find its place in the Software Development Life Cycle (SDLC) processes of most organizations until a few years ago. Its biggest challenge within the SDLC was its need for a target application to be up and running, which often happened quite late in the cycle. And, its biggest challenge for integration with ever-present automated build tools was the need for training the scan how to properly interact with the target application, which was done manually.

So, what changed all of this? DevOps. All of the sudden, barriers to inclusion in the SDLC fell, all at the same time. Suddenly, DAST automation, as a part of the DevOps CI/CD pipeline, not only became possible but actually offered a better starting point and is a good complement to a technology like SAST.

DAST Automation is very powerful when implemented properly. Here are some common cases when it could be used and why it's beneficial.

1. DAST and QA Functional Testing. The easy win here comes by leveraging functional test tools like Selenium. These tools are used to test an application's functionality and, therefore, know how to properly interact with it. If DAST tools can understand those interactions or the HTTP traffic generated by them, then you get everything you need to run a thorough scan of your application. This, in turn, leads to very good security scan coverage of your application without having to perform any extra work.

2. Incremental Scanning. A lot of modern software development practices rely on delivering incremental pieces of work that make their way into production a lot faster than they used to. This means that a lot of work that developers do has also become incremental. New functional tests must be developed in parallel to ensure that new features work as expected. DAST can then be used to leverage those new functional tests, not only to do incremental security testing of new or updated functionality but also to significantly reduce security testing times, making it ideally suited for the DevOps CI/CD pipeline.

3. Web Services.  It's important to specifically mention web services and, especially, REST APIs because they comprise a large portion of the "web app code" written today. And, since they are hidden behind front-end UI, people tend to forget they are just as likely to be attacked as a regular web application.  One of the benefits of DAST Automation is that it can be used as a framework for directly testing those web services for security vulnerabilities. This closely follows the model of the other two cases, where functional tests can be used to teach the security scan how to properly interact with each web service before doing a security test on it. This further ensures that all the basics are covered and attackers are less likely to target your applications.

4. Technologies of Tomorrow. And, there is one more case where DAST will be applicable. DAST relies on HTTP(S) traffic to perform the analysis. This means that the DAST is both programming language agnostic and is able to work across a wide variety of systems and services used on the back end. It does not care that you write your applications in Java, .Net, or Python. Or, whether you use Microsoft SQL Server, IBM DB2, or even a mainframe — it doesn't matter how many web services a request has to go through.  As long as the application relies on HTTP to communicate, DAST can usually be a very powerful tool to test your web applications and services.

In the end, it's up to each organization to determine how they approach application security.  Ideally, each company should establish an application security program that takes a multi-faceted approach to finding and mitigating risks that exist in their applications. Each technology mentioned at the beginning of this post has its own advantages and drawbacks. That said, DAST Automation is still relatively unknown and very much underutilized, even as organizations push towards adopting DevOps. An automated DAST approach can be a simple extension of existing functional testing and can provide a lot of benefit to security teams, developers, and application owners, with little delay or overhead. It's not always a perfect fit, but we definitely hope that organizations will take a deeper look at DAST as they build and refine their approaches to DevOps!