Split DAST by depth. Run a short passive scan of a few minutes on each merge, a time boxed active scan nightly or weekly against staging, and deep authenticated scans on a schedule. Pipelines stay fast, and slow scans still happen, just not where developers wait.
Why one scan cannot do everything
Active scanning sends attack payloads and can take hours on a large app. Passive scanning only observes traffic and finishes quickly. Putting an hours long job in the path of every pull request teaches developers to bypass it.
The ZAP project documents this split. Its baseline scan spiders a target for one minute by default, then waits for passive scanning to finish, and the page says the whole run is a few minutes at most. It states the script does not perform actual attacks and calls it ideal for CI/CD. Its API scan, by contrast, imports an API definition and runs an active scan against the discovered URLs.
A three tier budget
| Tier | Trigger | Depth | Target time | Fails the build |
|---|---|---|---|---|
| Fast | Every merge to main | Passive only, short crawl | Under 10 minutes | Only on a short list of high confidence rules |
| Nightly | Schedule | Active scan, time boxed, staging | 1 to 3 hours | No, opens tickets |
| Deep | Weekly or per release | Authenticated, full crawl and API import | As long as needed | Release gate for high severity |
The target times are starting points to adjust against your own pipeline, not standards.
Steps to set it up
- Measure how long each scan takes on a warm environment today.
- Choose the fast tier budget by asking developers how long they will wait. Anything above ten minutes needs a reason.
- Put every rule on a three level setting: ignore, warn, fail. The ZAP packaged scans use a config file for exactly this, where rules default to warn and exit codes report whether any rule failed or only warned.
- Exclude URLs that waste time, such as static assets, third party hosts and endlessly paginated lists. Packaged scans accept regex based out of scope lines for this.
- For active rules, remember that setting a rule to ignore in the API scan config also stops it running, which shortens the scan.
- Review runtime monthly. Scan time grows with the app.
Make the slow scans useful
A nightly scan nobody reads is wasted compute. Route its findings to the owning team, deduplicate against open tickets, and report new findings only. For how often to run each type, see how often to run SAST, DAST and SCA.
Try it yourself
Open the demo and compare what a quick scan reports with what a fuller one adds.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers policies and gates that can be applied at pull request and pipeline stages. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Should a DAST scan block merges?
Only the fast tier, and only on rules you trust. Slow active scans are better as scheduled jobs that open tickets.
Can I run active scans against production?
Be cautious. Active payloads can create data or trip alarms. Staging with production like data is the safer default.
Sources
Last reviewed: 19 October 2026.
