What is wrong with the current state of DAST? Feedback from my conversations with AppSec engineers

When I launched this study, my goal was to determine whether most, if not all, AppSec engineers still perceive DAST as a checkbox in application security programs. I wanted to understand what led them to think that DAST is just a necessity rather than a useful tool. 

I asked most of the AppSec engineers a simple question “I saw that there were a lot of negative opinions on DAST, but it’s gradually changing - do you have a take on this? “ From there, the conversations often took off, and while some answers were quite short and direct, others were more nuanced. I also gathered feedback throughout the year - from the Elephant in AppSec podcast conversations, LinkedIn posts, and face-to-face chats - just to get a wider variety of perspectives on DAST.

While it didn't get to the essay responses like sometimes I got with shift left, I was still quite positively surprised by the depth of the answers. It felt like some engineers definitely needed space to express their opinions on DAST. 

For any readers, please keep in mind that this is still a small subset of AppSec engineers. As with the podcast, I focus on opinions rather than on quantitative data. Everyone is entitled to their own opinions, so if you disagree with any trends seen below, feel free to reach out on LinkedIn to discuss further. My door is always open for strong takes!

TL;DR

Most AppSec engineers are actually not that negative, but… it depends. On a lot of factors.

I used to be very negative about DAST, because it was so limited in what is could find, lacked intelligence, and was extremely resource and time consuming. However, today, I have a more positive opinion - Head of Application & Product Security, Dematic

AppSec engineers have mixed feelings about DAST. While many are not overly negative, their perspectives depend heavily on the maturity of their security programs and the specific challenges they face in their environments.

Key frustrations with DAST:

1. Too much configuration is required to get the value out of the tool:  Fine-tuning makes it hard to scale
2. Which leads to a high number of false positives from many DAST tools on the market

However, DAST is becoming increasingly effective as new tools leverage AI to intelligently detect business logic vulnerabilities, understand the architecture of modern applications, and automate tasks that previously required manual configuration.

In a broader view, the success of DAST depends on

1. The maturity of the security program - this was the key point among at least 10 conversations

2. The resources and time that can be dedicated by your team to setup and configuration

3. The specific environment and application being tested

The main frustration with DAST - too much configuration is required to get the value out of the tool

You can probably guess from the title what the key frustration with DAST is. If you've ever worked with it, you've likely shared the same feeling - the frustrating amount of configuration required to make the tool useful has come up in nearly every conversation I've had with AppSec engineers.

As one Staff Security Engineer (Box) put it, “The issue is the time that can be allocated by engineers on DAST is not enough to tune it to a state where it is absolutely positive.” This sentiment captures the core of why many security teams struggle to fully leverage DAST. While the tool type definitely holds potential, it might demand a level of tuning and fine-tuning that simply isn’t feasible for AppSec teams already stretched thin.

1 security person per 50 to 100 developers? While sometimes it holds true, more often than not, it's far from reality, and AppSec engineers are looking for more hands-off automation to scale their efforts (this is also the number one pain I often hear when people reach out to us at Escape)

This constant tweaking of DAST takes valuable resources and time, which security engineers might feel could be spent elsewhere in a security program:

You typically have the problem to decide, do I do DAST or SAST in the start? And when you go for SAST, you need a little fine tuning to get less false positives. While in DAST, you have the problem of the configuration. - Timo Pagel, Lead Security Architect

If you don’t have the bandwidth for such a resource-intensive process, or choose a tool that doesn’t automate certain parts of the scanning process (like spec generation when you test your APIs), it leads to mounting frustration, incomplete scans, missed vulnerabilities, and, ultimately, the tool not being used to its full potential.

Let's say API security is better if companies can reduce the manual steps (uploading specs, setting up notifications). Yeah, we are dealing with it and you have to upload your JSON files or Postman collection. And then you have to set the targets, but target is in the Postman collection mostly. So these are the manual steps that it's not fitting the DevSecOps ecosystem, I think, - Iman Ilbag, DevSecOps, KPN

That’s not to say that DAST doesn’t hold value - it does, but it may come up at a steep price in terms of time and expertise:

I think DAST is a good tool for appsec. Like everything, pros and cons. It's important to understand how it fits into your overall security program. That context allows you to properly tune it and increase the signal to noise ratio. - Nathan Cooke, Manager of Product Security, Alloy

The key takeaway here is clear: to change the perception of DAST and truly unlock its value (which I'll talk more about below) for AppSec engineers, DAST tools need to require less manual effort. We need solutions that actually help without increasing operational workload, not just more and more complex tools.

When does DAST hold value, and is worth the investment?

The question isn't really "Are DAST tools any good?" but "When are DAST tools worth the investment?"That question brings up things like the maturity of your security program, the capacity of your team(s), and the accuracy and coverage of your documentation, - Nathan Cooke, Manager of Product Security, Alloy

From my conversations, I found that most of the time, the key to DAST being worth the investment isn’t whether it’s a “good” tool, but when it’s the right fit for the organization.

While legacy solutions like Tenable, Rapid7, and Qualys are often mentioned for specific use cases, such as basic compliance checks, "they’re of little use beyond that"- especially when more complex application security testing is needed. But compliance continues to drive DAST implementation. As one Principal Cyber Security Architect (Mercredez Benz Financiam Services USA) put it, DAST is “Worth the investment and now a potential requirement for most EU businesses due to DORA.” (DORA places a strong emphasis on automated testing and ongoing security assessments to ensure resilience, I also wrote an article on this topic). So, DAST is here to stay as a "mandated" investment for many organizations, but we must adapt the tools to deliver real value beyond mere compliance.

A critical consideration for DAST's ability to deliver value is the maturity of the organization’s security program. One Application Security Analyst (Nomad) highlighted, “Another crucial factor is the level of maturity of companies that use or wish to use DAST in the pipeline. They need to have high maturity and know precisely what is being done to avoid impacting the environment and to prevent delays in continuous deployment checks.” This opinion was echoed by many others. It’s clear that DAST tools are most effective in mature security environments with well-defined processes for integrating security into development and deployment workflows.

Interestingly, maturity is not necessarily tied to the size of the organization. One product security engineer pointed out:

I think it really depends on the maturity of the engineering work because I've seen smaller startups under 100 employees that have DAST in a very mature way, have SAST in a very mature way and I've seen thousand plus employees that don't have it together.

This suggests that even smaller organizations can have effective, mature security practices in place to implement DAST efficiently, while larger companies might still struggle with their security processes.

That said, DAST still plays a critical role in the SDLC, particularly when it comes to complementing other security tools. As one Principal Cyber Security Architect, I interviewed noted:

Overall I think a DAST tool has its place in the SDLC/DevSecOps and can aide in identifying false positives coming out of your SAST/SCA scans.

DAST’s effectiveness also depends on how it is integrated into your security pipeline. “It can be effective, but its success often depends on how the tools are used, the scope defined, and the application being tested (Product Security Engineer, Splunk)". Defining the right scope for DAST scanning, along with careful tool selection and integration, is key to ensuring success.

When you start looking for the value that can actually be delivered by DAST tools, as the market for DAST tools continues to evolve, you have to be cautious when evaluating different vendors:

“If you read into all the different vendors and their 'DAST tools,' the definitions are vague and often applied differently per vendor/proprietary tool. You really have to pay attention to the complexity and depth of the tools due to the wide variety!”

Vendors can sometimes over-promise, using benefit-focused language without clearly explaining how their testing algorithms work. Personally, I’ve spent too much time analyzing various vendor documentation and trying to compare different DAST tools and understand, for example, the tests they offer... If it's not clear, you should definitely challenge it in the demo.

In conclusion, DAST can hold significant value, but its worth depends largely on the maturity of your security program, the specific use case, and the resources you can dedicate to its implementation and management. For organizations with the right conditions in place, DAST is a powerful tool in the security arsenal. However, for others, extracting value from DAST tools can be challenging without sufficient investment in time, resources, and expertise. This is where innovation in the DAST space could make a real difference, offering solutions that ease the burden on security teams while delivering more actionable insights with less manual effort.

Potential for innovations in DAST and Alternatives in the space

Based on my conversations, there are several promising directions where the DAST can go:

1. The need for automation (not just the need, but the necessity at this point)

Again, let's start with a key pain point, as mentioned already above, one thing I’ve repeatedly heard from security professionals is the challenge of fine-tuning DAST tools to the point where they deliver the most accurate results.

Fine-tuning is hard to scale, any steps to automate that process will increase the value of DAST tools. - Nathan Cooke, Manager of Product Security, Alloy

There’s huge potential for innovation here, especially when you consider things like spec generation for APIs, seamless authentication, and better integration with CI/CD. If DAST tools can automate more of the fine-tuning process, they would save security teams a significant amount of time and effort, allowing them to focus on higher-level tasks.

2. New DAST Tools for Modern Web Apps

Older tools such as Burp and ZAP, which don't play well with modern web apps (e.g. React SPA) - Staff Application Security Engineer, Ironclad

One of the key pain points I’ve identified in DAST is the difficulty older tools like Qualys, Burp Suite, and ZAP have in dealing with modern web applications, particularly Single Page Applications (SPAs).

The rise of new DAST tools designed specifically for SPAs presents an exciting opportunity to address this gap. It’s clear to me that the future of DAST lies in the ability to keep pace with how web applications are evolving.

3. The intelligent use of AI in DAST

Another area for potential innovation in DAST was the emergence of artificial intelligence behind the DAST algorithms. As a Head of Application & Product Security at Dematic I spoke with said, “The emergence of the intelligent use of AI in the DAST and the automated/semi-automated pen testing world strikes me as extremely promising, potentially leading to much higher value DAST solutions in the future.” I couldn’t agree more with this sentiment.

AI has the potential to bring a level of sophistication to DAST tools that we've never seen before. Beyond just identifying vulnerabilities, AI can help understand the underlying business logic of an application and identify  IDORs, SSRFs and Access control issues, which is crucial for modern web applications. It could ultimately lead to DAST solutions that are not only more efficient but also much smarter in their ability to deliver value to organizations.

4. ASPMs role in enhancing DASTs value

It’s also important to note that DAST doesn’t have to work in isolation. In fact, it can be highly effective when used in conjunction with ASPM solutions. Interestingly enough, most ASPMs struggle on the DAST side or integrate ZAP wrappers. So you need to find a DAST x ASPM tool combination with a great synergy to build a solid security foundation, allowing teams to identify and address vulnerabilities better.

In addition to these potential innovations, some engineers also mentioned some alternative approaches, particularly for smaller-scale organizations or those with unique needs.

For smaller organizations, one interesting trend I’ve noticed is the development of in-house security testing frameworks. As one Staff Application Security Engineer (Ironclad)  put it, “In my current position, scale is not the main problem (most of our code is within a couple of mono repos, and runs on a couple of k8s clusters), which allows me to substitute DAST with a security testing framework I’ve developed myself.”

Some security engineers also mentioned alternative approaches they prefer like IAST as alternative for DAST (this was common across the large organizations based in the EU). One thing I’ve learned, though, is that IAST comes with its own set of challenges. Specifically, it requires installing an agent on the application being tested. This adds complexity to the deployment process, which is not usually the case with modern DAST tools.

As the space evolves, I’d love to see how these innovations and alternatives will help AppSec engineers better secure their applications and optimize the efficiency of their security workflows!

General sentiments

If there’s one takeaway I have from all my research and conversations, it’s this: DAST can deliver significant value, but you need to ensure the tool you're implementing is truly efficient and won’t just consume more of your time.

Make sure your organization is mature enough to handle the tool, avoid unnecessary frustrations, and that the DAST vendor can deliver on their promises - ultimately helping you win the hearts and minds of your development team.

Security should woven into the fabric of development, rather than addressed reactively.

Also, I believe that choosing the right security solution is not just about optimizing efficiency - it's about enabling your security and development teams to work together seamlessly and achieve their shared goals. And it also concerns DAST. The statement below from one of my podcast guests, Alek Krasnov, really resonates with me:

"So it's not really about how to make DAST more efficient. It's more about how to make the engineering team to succeed"