Learn why scans that used to be a compliance checkbox are being reinvented as actionable, frictionless security workflows.
Similar to Cassandra from Greek mythology, DAST was once used to generate warnings that no one listened to. Security teams would run DAST tests, generate a report, and move on to the next challenge, knowing that most findings would never be addressed.
But the conditions that allowed DAST to run under the radar have changed. Today’s app development teams only have bandwidth for testing that results in real issues getting fixed, while the consequences of ignoring those issues are becoming increasingly serious.
Here’s why attitudes to DAST are changing, and why a new generation of DAST is already meeting that bar.
DAST of Yesterday Versus Today
Once upon a time, DAST operated under little pressure. The release cycle only shipped a few times a year, so teams could reasonably run DAST on a periodic cadence of pre-release or quarterly scans. Compliance frameworks directly encouraged this approach. PCI DSS Requirement 11.3 calls for externally facing components to be tested annually and after significant changes, while other frameworks call for quarterly vulnerability scans.
When findings did arrive, it was as a URL and a payload, not a repository location or line of code. Security engineers had to manually investigate the full app to discover where exactly the bug lies, a level of friction that was acceptable when scans were infrequent and the volume of issues was low.
What’s more, bugs weren’t linked to a specific repository or team. No one bore responsibility for ensuring that they were fixed. DAST findings sat in a security dashboard rather than the project management tools that developers regularly consult, leaving security teams to review the dashboard, validate each finding, work out which dev team owns that piece of code, and hand it over. It’s a process that only works when alert numbers remain small.
As a result, DAST functioned as a compliance checkbox rather than an engineering output. Unlike SAST, which ties bugs to a file and line location and leads to remediation actions, DAST served solely as evidence that scans had taken place. For overstretched security teams, this division of labor kept them from getting overwhelmed, but it didn’t make use of DAST’s full potential.
While this approach worked fairly smoothly for some time, the security scenario has changed, as have the tools. The manual, high-friction process of fixing bugs revealed in intermittent DAST scans isn’t sustainable in today’s high-velocity, high alert volume reality. That model is breaking down, and it’s exactly what modern DAST implementations are built to fix.
Release Velocity
Code shipping no longer matches the traditional DAST scan cadence. CI/CD methodologies and on-demand deployment mean that vulnerability scanning needs to take place more frequently. By the time a quarterly or even monthly audit occurs, the code has changed hundreds of times and the findings are outdated, before cyber and engineering teams have even finished reviewing the report.
DORA’s 2025 State of DevOps research revealed that while approximately 24% of organizations still deploy less than once a month, about 16% deploy multiple times per day, with the gap between low performers and elite performers widening to as much as 60x. Continuous, CI/CD-native scanning closes that gap, running DAST scans on every build instead of waiting for the next audit window.
API Sprawl
Unlike traditionally monolithic software applications, modern apps expose hundreds of endpoints. They’re dynamic webs of microservices, third-party integrations, and internal APIs, moving too fast for inventory practices to keep up. Legacy DAST tooling can’t see every endpoint, and it can’t scan what it can’t see.
Additionally, API sprawl makes it extremely difficult for security personnel to track down and locate serious bugs. Manual app investigations are no longer tenable at this scale, creating a bottleneck that throttles code release and threatens app security. Newer DAST approaches that discover endpoints from source code and API specs, instead of relying on manual inventory, are starting to close that visibility gap.
AI-Generated Code Volume
The arrival of AI-powered coding has been great for dev productivity, but it’s a nightmare for security teams. Individual developers often skip manual review and ship code straight to production, so runtime issues surface immediately in the live environment.
Security teams can’t triage fast enough, and the speed of code production keeps accelerating. The security backlog is spiraling out of control, with the security team falling further and further behind and leaving the company increasingly exposed to cyber threats. This is precisely the scenario runtime-context DAST is designed for, catching what ships before triage even starts.
Shift-Left Fatigue
Devs already expend significant energy fixing SAST and SCA bugs early in the pipeline. They have no bandwidth left for alerts that serve only to meet a compliance checkbox and zero tolerance for interruptions from another security tool, even if it’s revealing unique bugs.
Moving DAST left into the dev process will only work if it delivers a frictionless, integrated experience that delivers clear and instant instructions on how to fix the bugs it finds.
What DAST Needs to Deliver to Remain Relevant
Against this backdrop, DAST has to become truly actionable if developers are actually going to use its findings and fix the bugs it uncovers.
That must include:
- Reproducible evidence like the exact HTTP request and the server’s response, not just a vulnerability code name.
- The specific GitHub/GitLab repository and code path that maps alerts to the team that owns them.
- Exploitability context that demonstrates whether a bug is truly critical.
All results need to arrive where developers actually manage their workflows, in platforms like Jira or Slack, not in a separate security dashboard.
Revamped DAST for a New App Security Reality
When teams adapt DAST to the ways that code actually ships today, it turns a compliance symbol into a critical pillar for app security. Devs receive the filtering and handoff details they really need without alert fatigue, security teams stop chasing fires and actually clear their backlog, and product quality goes up. What might sound like the death knell for DAST is actually leading to its rebirth.
