DAST, dynamic application security testing, tests a running web application from the outside, the way an attacker would, looking for weaknesses that only show up when the app is live. To a CFO: it is a scheduled outside inspection of the product, separate from reading the code.
The simple version
Picture a shop. Reading the blueprints is one kind of check, and that is what code analysis does. Walking up to the front door and trying the handles, windows and delivery entrance is another, and that is DAST. Both find problems the other misses.
The OWASP Web Security Testing Guide is the community reference for how web application testing is done. It describes itself as a leading testing resource for developers and security professionals. A DAST tool automates a slice of that work against a running system.
What does the business get?
Evidence for customers. Buyers send security questionnaires and ask whether you test your running application. A dated report is a direct answer.
Fewer surprises. Problems found in testing cost time to fix, but less than problems found after a customer or attacker reports them. We will not put a number on it, because the figures you see quoted are rarely tied to your situation.
Support for compliance. Frameworks that ask for regular security testing of applications are easier to meet with a schedule and records.
What does it not do?
Be straight with finance about the limits. DAST only tests what it can reach. It needs a running environment, valid logins for pages behind sign-in, and care to avoid damage to test data. It can miss logic flaws that need business context. It reports issues in the running app but does not point at the line of code by itself, so developers still need to trace the cause.
That is why teams pair it with other checks: code scanning before release, dependency checks, and manual testing for sensitive features. DAST is one layer, not the whole program.
What drives the cost?
Ask for a cost view in four parts, and avoid a single figure.
- Licence or service fees. Per application, per scan, or per seat, depending on the product.
- Setup time. Configuring logins, scope and a safe test environment takes engineering effort.
- Triage time. Someone must review findings and drop false alarms. Poor tuning makes this the biggest line.
- Fix time. Developer hours to close real findings.
If a vendor quotes only the first line, ask about the other three.
How do you tell whether it is working?
Track a few plain measures: number of applications scanned on a schedule, time from finding to fix for serious issues, percent of findings that turned out to be real, and how often scans fail to complete. Report them quarterly in one slide.
Is DAST the same as a penetration test?
No. A penetration test is performed by people who can chain findings and judge business impact. DAST is automated and repeatable, so it complements a pen test rather than replacing it.
What to do
- List your internet-facing applications and rank them by business importance.
- Choose a safe test environment with realistic data that is not production customer data.
- Run a pilot on one application and record triage and fix effort.
- Show finance the four-part cost view and the quarterly measures.
- Pair DAST with code and dependency scanning, and schedule a manual test for critical features.
Quick check
Can DAST run in production?
It can, but many teams avoid it because scans can create data or load. A staging copy is the safer default.
Does DAST find everything?
No. It tests what it can reach, and misses flaws that need business logic or knowledge of the code.
Sources
Last reviewed: 18 October 2026.
