What is a DAST scan policy and how do you tune one?

A DAST scan policy is the setting that decides which attack rules a scanner runs and how aggressively it runs them. Tuning it changes scan time, request volume, false positives and missed issues. Start from the default, then adjust one lever at a time and compare results.

What a policy controls

The ZAP documentation describes a scan policy as defining which rules are run and how they work, and notes it influences how many requests are made and how likely potential issues are to be flagged. You can keep several policies and pick one at scan start. Other tools use different words but the same idea: a named bundle of rules plus intensity settings.

Two levers matter most.

• Strength (sometimes called attack intensity): how many attack variations a rule tries. More variations means more requests and a longer scan.
• Threshold: how confident the scanner must be before it raises an alert.

What the threshold really trades

ZAP's policy dialog documentation spells the trade out. A Low threshold raises more potential issues, which may increase false positives. A High threshold raises fewer, which may mean some real issues are missed, the false negatives. The same page warns that the highest strength level should usually be kept for small parts of an application, because it can produce a very large number of attacks and take a long time.

How to tune, step by step

1. Run the default once against a stable test target and save the report.
2. Time the scan. Note duration and request count. If it fits your window, do not touch strength yet.
3. Look at the noise. If most alerts are false positives for one rule category, raise the threshold for that category, not for everything.
4. Add depth where risk is high. Raise strength for the login, payment or file upload areas and keep it modest elsewhere.
5. Switch off irrelevant rules. A rule for a technology you do not use only adds time. Write down what you disabled and why.
6. Re-run and compare. Confirm known findings are still found. A tuned scan that loses a known bug is a regression.
7. Lock the policy. Some tools can lock a policy so new rules are not added by accident. The ZAP documentation describes locked policies as preventing the use of rules other than those defined in the configuration. That helps repeatability, but remember to review new rules on a schedule.

Keep different policies for different jobs

A pull request check and a weekly deep scan do not need the same policy. A short, low-impact policy gives fast feedback on every change. A fuller policy runs on a schedule against staging. Naming them by job, such as "pr-fast" and "weekly-deep", makes the intent clear to the next person.

Mistakes to avoid

• Raising every setting to the maximum and then abandoning the scan because it never finishes.
• Lowering everything until the report is empty, then calling the app clean.
• Changing three levers at once, so nobody knows which change caused a missed finding.
• Forgetting to version the policy file next to the code.

A worked example

A team runs a weekly scan on a customer portal. The default policy takes five hours and produces 120 alerts, of which a sample of 20 shows 14 are noise from one rule category about cache headers. The team makes these changes, one per run.

The figures are an illustration of the method, not measurements from a real system. What matters is that each run changed one thing, and that a set of planted known bugs gave a fixed reference. If run 3 had found only 3 of 4, the team would have reverted that change.

Planting known bugs

A tuned policy needs a ruler. Many teams keep a small test page or a staging fixture with a handful of deliberate flaws, such as a reflected input and a missing access check. After every policy change, rerun the scan against it. If a planted bug disappears, the change cost you coverage.

Policy hygiene

• Name policies by job, such as "pr-fast", "nightly" and "release-deep".
• Keep the policy file in version control. A diff then shows who changed a threshold and when.
• Review new rules. When the scanner updates, new rules may arrive switched on or off. Read the release notes and decide.
• Write down every disabled rule and the reason. Disabled rules are blind spots by choice, and they should be a conscious choice.
• Revisit after major app changes. A move to a new framework or database may invalidate earlier decisions.

Questions for a tool you are evaluating

1. Can I save and share policies as files?
2. Can I set strength and threshold per rule category and per path?
3. Can I lock a policy so new rules are not added silently?
4. Does the report show which policy ran?
5. Can I compare two runs?

If the answer to the last two is no, tuning becomes guesswork, because you cannot prove what changed.

Where Safeguard fits

Scan policies tune what a web scanner does. They do not tell you about vulnerable libraries inside the app. For that, Safeguard provides SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Follow the scan from start to results and note which stages would take longer at a higher strength.

Quick check

Sources

• ZAP: Scan Policy
• ZAP: Scan Policy dialog

Last reviewed: 19 October 2026.