DAST benchmark results show coverage and false positive tradeoffs

At a glance

What this is: This is a DAST benchmark that compares Escape, Qualys, ZAP and Intruder on Gin & Juice Shop and finds that coverage, authenticated scanning, and false positive handling shape real-world value more than raw runtime.

Why it matters: It matters because AppSec and DevSecOps teams need scanners that can authenticate, crawl modern apps, and surface actionable findings without overwhelming triage or slowing delivery.

By the numbers:

• Escape recorded 93.18% coverage on the Gin & Juice Shop test application.
• Escape sent 7,630 requests, far fewer than Qualys at 82,536 and Intruder at 73,549.

Context

DAST tools are only useful when they can authenticate, crawl the application structure, and produce findings that security teams can actually triage. In modern web apps, scan quality is often constrained less by raw speed than by setup friction, coverage depth, and how much noise the tool creates while trying to reach business logic.

This benchmark sits squarely in that governance gap. For AppSec and DevSecOps teams, the practical question is not whether a scanner can generate output, but whether it can discover meaningful weaknesses in authenticated paths without turning configuration and verification into specialist work.

Key questions

Q: What breaks when DAST cannot handle authentication properly?

A: Coverage becomes superficial because the scanner cannot reach the authenticated workflows where the most damaging flaws often sit. In practice, weak auth handling leads to false confidence, missed authorisation bugs, and blind spots in applications protected by SSO, MFA, or stateful sessions.

Q: Why do false positives matter so much in DAST programmes?

A: False positives turn security testing into an analyst workload problem. If the scanner cannot provide reproducible evidence, teams spend time validating noise instead of fixing real issues, which slows remediation and weakens trust in the tool. A DAST programme succeeds when findings are both numerous enough to be useful and accurate enough to act on.

Q: How should teams evaluate business logic testing in a DAST tool?

A: They should test whether the scanner can follow realistic workflows, preserve state, and reach application logic that generic payloads do not expose. A good result is not simply more findings. It is evidence that the tool can identify weaknesses in how the application behaves, especially in authenticated paths and client-side flows.

Q: How should teams balance DAST with other AppSec testing methods?

A: Use DAST to prove exploitability in running applications, then correlate it with code analysis, dependency scanning, and secrets detection to understand why the issue exists and how broadly it matters. The tools are complementary, but runtime validation should drive the final priority because it shows what can actually be reached.

Technical breakdown

Authenticated crawling and coverage in modern web applications

DAST depends on the scanner's ability to behave like a realistic user session. That means following links, handling JavaScript-heavy flows, preserving session state, and reaching paths that are invisible to unauthenticated checks. Coverage is therefore a structural property of the crawl, not just a tally of pages visited. If authentication or session handling fails, the tool may report success while missing the parts of the application that matter most. Modern apps also complicate crawling with CSRF tokens, client-side routing, and dynamic content, so the quality of the scanner's browser automation becomes central to its usefulness.

Practical implication: Treat authenticated crawl coverage as a gate for tool selection, not a tuning detail.

False positives and proof of exploit in DAST triage

False positives are the point where detection becomes operational debt. A scanner can find many issues, but if the findings are poorly evidenced or not reproducible, AppSec teams spend more time validating noise than remediating risk. Proof of exploit changes that equation by giving analysts a concrete way to separate a real vulnerability from a weak signal. In practice, this shifts DAST from a detection-only tool toward a triage workflow, where evidence quality and reproducibility matter as much as the number of alerts. That is especially important for issues like XSS, injection, and client-side weaknesses, where context determines whether the finding is actionable.

Practical implication: Prioritise tools that produce reproducible evidence, not just high issue counts.

Business logic testing versus broad vulnerability enumeration

Business logic testing looks for flaws in how the application behaves, not just whether standard signatures or payloads hit a known pattern. That is harder than basic vulnerability enumeration because it requires the scanner to understand workflows, state changes, and the difference between safe and unsafe application behaviour. A tool that only enumerates generic issues may look busy but still miss the vulnerabilities that create real business impact. This is why coverage, authentication, and request efficiency all matter together: they create the conditions under which logic-aware testing can happen at scale.

Practical implication: Evaluate whether the scanner can reach logic-bearing workflows, not only whether it can flag common CVEs.

Threat narrative

Attacker objective: The underlying security objective is to identify which scanner can most reliably surface exploitable application weaknesses in realistic authenticated sessions.

1. Entry occurs through authenticated application flows that the scanner must be able to reach, because unauthenticated surface-only checks miss many real weaknesses.
2. Credentialed access and crawl depth determine whether the scanner can observe session-bound routes, CSRF-protected actions, and business logic branches.
3. Impact is measured by whether the tool exposes exploitable issues with enough evidence to support remediation instead of flooding analysts with noise.

Breaches seen in the wild

• Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DAST value is now defined by coverage quality, not scan volume. A scanner that reaches more of the authenticated application surface has a materially different security value than one that simply produces more traffic or more findings. That distinction matters because modern applications hide risk behind session state, JavaScript flows, and business logic. For practitioners, the real question is whether a tool can see the app the way an attacker would.

False positive management is a governance problem, not just a tuning problem. When a scanner creates more questionable alerts than actionable findings, the cost lands on analysts, engineers, and release velocity. That makes triage efficiency part of the control objective, not an afterthought. Teams should judge DAST by the credibility of its evidence and the time required to validate findings, because alert quality determines whether testing changes outcomes.

Business logic testing is becoming the differentiator between commodity scanning and usable AppSec signal. Standard signatures still matter, but they do not cover the application-specific flows that often hold the most damaging weaknesses. That pushes the market toward scanners that can reason about workflows, not just page structures. The governance implication is clear: AppSec programmes need tools that can assess how an application behaves, not only what it exposes.

Authenticated coverage is the control boundary modern AppSec teams keep underestimating. The benchmark shows that a scanner may look efficient while still failing to reach large parts of the live application experience. In practice, that means teams should treat authentication, crawl state, and session continuity as part of the security control design. If those are weak, the scanner never gets the chance to test the real risk.

What this signals

Coverage is the control boundary that separates useful DAST from report generation. Teams should expect modern scanners to prove they can reach authenticated workflows, because unauthenticated surface scans leave the most relevant risks untouched. In practice, this means coverage metrics belong in procurement and tuning conversations, not just in post-scan reporting.

Triage quality now defines operational adoption. If analysts cannot quickly separate evidence-backed findings from background noise, the programme will drift back to manual verification and exception handling. That makes proof quality and reproducibility central to programme design, especially where development teams need fast, reliable feedback.

Business logic visibility is the differentiator that matters for modern web apps. Applications increasingly hide risk in workflow decisions, state transitions, and client-side behaviour rather than in obvious misconfigurations. AppSec teams should therefore judge DAST by how well it reveals those paths, not by how much traffic it generates.

For practitioners

• Define DAST acceptance criteria around authenticated coverage Require evidence that the scanner can reach session-bound paths, handle login state, and exercise the app's business workflows before you compare issue counts.
• Measure triage cost alongside vulnerability output Track how many findings are reproducible, how many are false positives, and how long analysts need to validate each report before adopting a tool.
• Test business logic paths explicitly Include workflows with state changes, client-side behaviour, and protected actions in benchmark runs so you can see whether the scanner finds issues that matter.
• Separate setup friction from scanning quality Score the time needed to configure authentication, crawling, and scan profiles independently from the final result set so ease of use does not hide weak coverage.

Key takeaways

• DAST tools now compete on how well they reach authenticated application paths and produce evidence that analysts can trust.
• Coverage, false positives, and business logic visibility create the real tradeoff, not scan speed alone.
• AppSec teams should evaluate scanner usefulness by how much of the live workflow it can see and how expensive its findings are to triage.

Key terms

• Authenticated Coverage: Authenticated coverage is the ability of a security testing tool to exercise logged-in workflows, role-specific functions, and tenant-bound paths. It matters because many critical application weaknesses only appear after access has been established, which means unauthenticated scanning can miss the highest-risk behaviour.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Business Logic Security Testing: Business Logic Security Testing is the practice of testing whether an application allows actions that violate intended workflow rules, role boundaries, or object ownership. It focuses on how the system behaves across sessions and states, which is why it can expose flaws that standard payload-driven scanners miss.
• Proof of Exploit: Evidence that shows why a reported issue is credible, such as request traces, payload effects, or a reproducible exploitation path. Strong proof of exploit shortens validation time and helps teams distinguish real vulnerabilities from noisy scanner output.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs a stronger control foundation for identities, access, and governance.