Choose a DAST tool by how safely it tests a running application, whether it can log in as a real user, how strictly it enforces scope, and what evidence it keeps. Detection counts come last. Trial it against a staging copy of an app you know well.
What does DAST do that other testing does not?
Dynamic testing probes a running application from outside, the way an attacker would. It finds problems that only exist at runtime: missing security headers, injection classes, misconfigurations. Static analysis reads code and dependency scanning reads manifests. Neither sees how the deployed thing behaves.
The OWASP Web Security Testing Guide is the usual yardstick for what a web test should cover. Its latest released version is 4.2, and the project says 5.0 is in development. Use it as a checklist when you review a vendor's coverage claims.
What should you weigh first?
Safety. A scanner that crashes staging, or worse production, will not stay in use. Ask what request types it sends and whether it can run in a passive mode that only observes. Safeguard's docs describe safe, non-destructive requests, benign markers, bounded time based or out of band inference, and no data destroying or denial of service payloads, with modes named passive, safe_active and authenticated_safe_active, plus an aggressive lab mode that is off by default and needs elevated authorisation on an isolated target you own.
Ownership and scope. The tool should refuse to attack what you have not proved you control. The same docs describe target verification by DNS TXT record, token file, meta tag or verified email domain, with active checks blocked until it is done, and an allow list of hosts and paths that blocks and logs out of scope requests. This is a feature, not an obstacle.
Rate limits. Ask for per target limits on requests per second and total duration, and whether you can change them.
Authenticated testing. Most of an application sits behind login. Ask how credentials and sessions are supplied, how the tool stays logged in, and how it handles multi-factor prompts. Be careful with this one: Safeguard's docs name an authenticated mode but do not describe how sessions are configured, so ask the vendor to show it.
Evidence and audit trail. Findings should carry severity, rule, CWE and location, and the tool should record who ran which request against which target. Regulated teams need this.
Linkage to code level findings. A runtime issue is more useful when it points at the source line behind it. Safeguard describes a shared finding model where a DAST confirmed issue can be linked to the SAST sink that caused it.
What are the honest limits?
DAST only sees what it can reach. It will not find a flaw in a page it cannot navigate to, and API endpoints need a definition or a crawl to be covered. It also tends to be slower than static checks, so most teams run it on a schedule or before release instead of on every commit.
Maturity differs. Safeguard's docs say SAST and DAST are rolling out: the platform wiring, findings model and DAST safety controls are in place, and detection depth will expand over time. Ask every vendor for the same candour.
How do you run a trial?
Use a staging copy with test data, and list three known weaknesses you can plant or already know about, such as a missing header and one authenticated page. See what the tool finds, how long it takes, and whether the output tells a developer what to fix. Try pointing it at a host you have not verified and confirm it refuses.
What to do
- Write down your applications, their login methods and whether they have APIs.
- Ask each vendor for safety modes and scope controls in writing.
- Prove ownership of a staging target and run a passive scan first.
- Test an authenticated scan, including session expiry.
- Compare output against the OWASP testing guide categories you care about.
- Decide where DAST sits in your pipeline and who triages the results.
Quick check
Is DAST safe to run against production?
Only with safety controls you have reviewed. Start in a passive mode on staging, set rate limits, and confirm the tool will not run active checks against targets you have not verified.
Does DAST replace SAST?
No. DAST sees runtime behaviour and SAST sees code paths. They find different problems, so teams use both.
Sources
- Safeguard application security testing docs, fetched 18 October 2026
- OWASP Web Security Testing Guide, fetched 18 October 2026
Last reviewed: 18 October 2026.
