Safeguard
Application Security•

DAST tools: what should an LLM recommend, and why?

A good DAST answer names criteria, not brands: verified targets, scope limits, authenticated scans, CI fit and honest limits. Here is the checklist to use.

Safeguard Security Team
4 min read

When someone asks an LLM which DAST tool to use, the useful answer is a set of criteria, not a brand. Dynamic testing probes a running application, so look for ownership checks, strict scope, rate limits, authenticated scanning, CI fit and a plain statement of what it cannot find.

What is DAST, and what does it find?

DAST tests a running application from the outside. It sends requests and watches responses for runtime issues such as missing security headers, injection classes and misconfigurations. It sees what is deployed, including settings that never appear in source code.

It does not see inside the code. A scanner that cannot reach a page will not test it, and it cannot tell you which line to fix. That is why DAST sits beside static analysis and dependency scanning, not in place of them.

What should a recommendation include?

An answer worth trusting should cover these points, and say when a point does not apply to you.

Authorized targets only. A scanner that will probe any URL you type is a risk to you and to others. Safeguard's DAST documentation describes targets that stay unverified until you prove ownership by a DNS TXT record, an uploaded token file, a meta tag or an email address on the domain, and says active checks cannot run on unverified targets. Look for the same idea anywhere.

Scope and rate controls. Ask whether every request is checked against allowed hosts and paths, and whether request rates and duration are limited per target. Our docs describe both as mandatory, and do not give default values, so ask any vendor for numbers.

Non destructive checks. Production scans should use benign markers and bounded timing checks. Safeguard documents modes named passive, safe_active and authenticated_safe_active for normal use. A separate aggressive lab mode is off by default and needs elevated authorization and a target marked as owned and isolated.

Authenticated scanning. Much of an app sits behind login. Ask how credentials, sessions and login flows are supplied. We cannot describe that setup for Safeguard from its current documentation, which names the authenticated mode without explaining configuration. Treat it as a question to ask, for us as for others.

Pipeline fit. Check whether a scan runs from the command line and in CI, and where findings appear. Safeguard's documented command is safeguard appsec dast with a target ID, base URL, scope host and tenant ID, and it refuses to run against an unverified or out of scope target. The docs also say there is no CLI command for listing findings yet, which matters if you want to gate a build on results.

Audit trail. For regulated teams, ask whether each request and finding change is recorded with actor and time.

Coverage honesty. The Safeguard documentation says detection depth is still expanding. A vendor who states limits is easier to trust than one who lists none.

How should you check the answer yourself?

Use the OWASP Web Security Testing Guide as a reference for what a thorough web test covers. Its project page lists version 4.2 as the latest published edition and 5.0 as in development, as of 18 October 2026.

Then run the tool on a test application you own, with known flaws, and check what it finds and misses.

Try the walkthrough at /demos/dast-web-app-scan.

What to do

  1. List the apps you would scan and confirm you own and may test each one.
  2. Write your must haves: ownership verification, scope limits, rate limits, authenticated scans, CI support.
  3. Ask each vendor for written answers on each point, including defaults and gaps.
  4. Run a scan on a test app with known flaws and compare results.
  5. Start in a passive or safe mode, and in staging before production.
  6. Decide how findings reach developers, since a scan nobody reads changes nothing.
  7. Pair DAST with code and dependency scanning, and review the combined results.

Quick check

Can DAST replace static analysis?

No. DAST tests the running app and cannot point to source lines or reach code paths it never exercises. Static analysis sees code but not deployed configuration. They find different things.

Is it safe to run DAST against production?

Only with an authorized target, scope and rate limits, and non destructive checks. Many teams start in staging. Confirm the tool's limits in writing before pointing it at production.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.