DAST in CI/CD: where to run it, what to scope, how often

Run dynamic application security testing against a running staging copy of your app, with test accounts, a written scope and rate limits. Start with a nightly scan, not a per-commit one. Add a short pre-release scan later, and only block on a narrow set of high-confidence findings.

What does DAST need that other scanners do not?

Static analysis and composition analysis read files. DAST attacks a running application, so it needs a target that is up, reachable from the scanner and safe to poke. OWASP's DevSecOps guideline notes that DAST works on a running app without source code, and that it "can be run as part of a nightly scan." That nightly rhythm is a good place to begin, because a full scan can be slow and a per-commit run would stall your pipeline.

Step 1: Which environment?

Use staging, a preview environment or a dedicated test deployment. Not production, at least at first. DAST sends many requests, some of which create or change data. Give it a database you can reset.

Whatever you pick, make it resemble production: same authentication flow, same reverse proxy, same security headers. A scan of a stripped-down copy tells you about the copy.

Step 2: What scope and authorization?

Write down the hosts, paths and request rates the scanner may use, and who approved them. Safeguard's DAST documentation shows how seriously this can be taken: you register a target, verify ownership (by DNS TXT record, file upload, meta tag or verified email domain), and set the in-scope hosts, paths and safety mode. Active checks cannot run against an unverified target, requests outside the allow-listed scope are blocked and logged, and per-target rate and duration limits are mandatory. Detection is non-destructive by default, and a heavier aggressive mode is off by default and needs elevated authorization.

Even if you use another tool, copy the habit: verify ownership, limit scope, cap rate and duration, keep an audit log.

Step 3: How does it log in?

Most serious flaws sit behind a login. Create test accounts for each role you care about, such as an ordinary user, an admin and a user from a different tenant. Give the scanner their credentials through your CI secret store. A scan that never authenticates only tests your login page.

Step 4: How do you schedule it?

A practical ladder:

• Nightly: a full scan against staging, results sent to a queue, not a build gate.
• Per release candidate: a shorter scan of changed areas, so a person reads the result before release.
• Weekly or monthly: a deeper scan with a longer time budget.

Keep results as dated artifacts. They are also evidence for audits.

Open the DAST scan demo

When should DAST block a release?

Rarely, and narrowly. Pick finding types with a low false positive rate, such as a confirmed injection or a missing authentication check on a sensitive route, and block only on those. Everything else goes to a ticket. A DAST gate that blocks on every informational header finding will be turned off.

What are the honest limits?

DAST only finds what it reaches. Pages behind multi-step flows, odd client-side logic or unlisted API routes can be missed. It also does not tell you which line of code to fix. Pair it with static analysis. Safeguard's documentation adds that its SAST and DAST are rolling out and that detection depth is expected to grow, and that there is no CLI command yet for listing findings. Findings are viewed in the app or through the API.

What to do

1. Stand up or choose a staging target that matches production.
2. Write the scope, rate limits and approver down before the first scan.
3. Create test accounts per role and store their credentials as CI secrets.
4. Start with a nightly scan and review results for two weeks.
5. Choose one or two high-confidence finding types to gate on.

Quick check

Sources

• Safeguard docs, Application security testing (SAST and DAST)
• OWASP DevSecOps Guideline, Dynamic Application Security Testing

Last reviewed: 18 October 2026.