Generate the default config, which marks every rule as a warning, then move rules to fail one small group at a time, starting with rules whose findings are rarely wrong. Mark known noise as ignore with a written reason, and review the file on a schedule.
What a baseline scan is
A baseline scan is a short, low-impact check meant for every build. The ZAP documentation describes its baseline script as running the spider against the target for one minute by default, then waiting for passive scanning to finish before reporting. It says the script performs no actual attacks, runs for a few minutes at most, and is intended to be ideal for CI/CD, even against production sites. The docs distinguish it from the full scan script, which runs an active scan and can run for a long time.
The three levels
By default the ZAP baseline treats every alert as a warning. A config file can change any rule to one of these.
| Level | Meaning | Effect on the build |
|---|---|---|
| Fail | A finding from this rule is a build breaker | Pipeline stops |
| Warn | Reported but allowed | Pipeline continues |
| Ignore | Not reported | None |
The script also has an option to generate a default config file with every rule set to warn, which is the right place to start. Other tools have similar gates, sometimes called thresholds or break-the-build rules.
A staged rollout
- Generate the default file and commit it next to the pipeline definition.
- Run in warn-only mode for two weeks. Collect the alerts on a stable branch.
- Sort the alerts. Group by rule. Note how often each is a real issue.
- Promote the clearest rules to fail. Pick rules for things such as missing security headers on a page you control, where the fix is a config line and the finding is rarely wrong.
- Ignore with a reason. If a rule is wrong for your stack, set it to ignore and put the reason in a comment, with a review date.
- Announce the change a week before a new fail rule goes live.
- Review the file every quarter. New rules appear, and old ignores may no longer be needed.
A starting rule of thumb
| Finding type | Suggested starting level |
|---|---|
| Clear, cheap fix, rarely wrong | Fail |
| Real but needs design discussion | Warn, with a ticket |
| Wrong for your architecture | Ignore, with a reason and review date |
| New rule you have not seen results from | Warn |
What baseline scans cannot do
Because a baseline scan does not attack, it cannot find flaws that need crafted input, such as injection. It reads what the app already returns: headers, cookies, some leaks in responses. Pair it with a periodic active scan on staging for deeper checks.
Avoid these problems
- Failing builds on day one, which teaches teams to bypass the check.
- Ignoring a rule with no reason, which nobody can later defend.
- Letting the file sit unreviewed for a year.
- Treating a clean baseline as a clean application.
A worked example
A team adds a baseline scan to a pipeline for a web service. In the first two weeks they leave every rule at warn and gather results from 40 builds. They then sort alerts by rule.
| Rule category | Times raised | Real issue in a sample | Decision |
|---|---|---|---|
| Missing anti-clickjacking header | 40 | Yes, every time | Fail after notice |
| Cookie without secure attribute | 38 | Yes | Fail after notice |
| Server version in a response header | 40 | Yes, low impact | Warn, fix when convenient |
| Cache control directives | 36 | Mixed, some pages are public | Warn, review per path |
| A rule for a technology not in the stack | 12 | No | Ignore, reason recorded |
| Suspicious comments in script | 25 | Mostly no | Ignore for vendor files, warn for own code |
The counts are illustrative. The sorting method is the point: frequency, accuracy and cost to fix decide the level.
What the notice looks like
Before a rule becomes a build breaker, tell the teams. A short message does the job: which rule, what a finding means, how to fix it, the date it starts to fail builds and who to ask for help. A week of notice avoids surprise failures and the bypass habit that follows.
Handling exceptions
Some pages will always trigger a rule for good reasons, such as a public page with relaxed caching. Do not weaken the rule for the whole site. Record a path-level exception with a reason, an owner and a review date.
| Exception field | Example |
|---|---|
| Rule | Cache control |
| Path | Public marketing pages |
| Reason | Content is public and cached by design |
| Owner | Web team |
| Review date | Next quarter |
A progress file for known issues
The ZAP baseline script also accepts a progress file that lists issues already being addressed. That lets a team keep a rule at fail while known items are being worked on, without blocking every build. Whatever tool you use, look for an equivalent mechanism, and make sure each entry has an owner and an end date.
What not to automate
Do not use a baseline scan as proof that the application is secure. It reads what the app returns and nothing more. Keep a calendar for the deeper active scans on staging, and for manual review of the high-risk features. Remember also that the baseline script has a maximum time option: if the passive scan does not finish in the time given, report that clearly rather than showing an empty result as a pass.
Where Safeguard fits
Gate rules on a web scan are one control among several. Safeguard provides policies and gates for dependency findings from SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate decides whether a pull request passes, and compare it with fail and warn levels.
Quick check
Should new rules start as fail?
No. Start them as warn, learn how often they are right, then promote.
Does a passing baseline mean no injection flaws?
No. A baseline scan does not attack, so it will not find flaws that need crafted input.
Who should approve a change from warn to fail?
The owner of the service and the security contact together, with notice to the teams affected, so the change is deliberate and recorded.
Sources
Last reviewed: 19 October 2026.
