Split checks by speed. On every pull request, run quick ones: spec checks, authorization tests and dependency scans. Run heavier active scans nightly or on release against staging. Gate merges on failures you trust, and keep slow or noisy checks informational until tuned.
A two tier layout
| Tier | When | Checks | Gate? |
|---|---|---|---|
| Fast | Every pull request | Spec diff against code, schema and lint checks, authorization tests, dependency scan | Yes |
| Heavy | Nightly or per release, on staging | Active API scan from the spec, authenticated, multi role | Yes for high severity, after tuning |
| Periodic | Monthly or quarterly | Manual review, business flow testing | Findings feed the backlog |
Authorization tests as the core
OWASP's Authorization Testing Automation Cheat Sheet recommends automating authorization tests so problems are caught when a release is built. Its approach is a matrix of features against logical roles, with integration tests that read the matrix as the only input. For each role the test obtains a token, calls every service and compares the response code with what the matrix expects. A failure should name the service and the role. OWASP API1 also says not to deploy changes that make authorization tests fail.
Using scanner exit codes
ZAP's API scan script returns exit code 0 for success, 1 if at least one FAIL, 2 if at least one WARN and no FAILs, and 3 for other failures. By default all alerts are treated as warnings, so decide which rule IDs should fail the build in the config file. A safe mode exists that skips active scanning and performs a baseline scan, which suits quick checks.
Keep builds fast
- Run the fast tier in parallel jobs.
- Cache dependencies and scanner images.
- Keep the heavy scan out of the pull request path.
- Fail only on rules with a low false positive rate, and promote others as you tune.
- Report findings in the pull request, with route and role named.
Handle noise honestly
A gate that fails often for no good reason gets bypassed. Review the first weeks of results, suppress with a written reason and an expiry date, and keep a record. That record doubles as audit evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Watch what a gate decides and how a finding is shown to the author.
Quick check
Should an active scan run on every pull request?
Usually not. It is slow and needs a deployed target. Nightly against staging is a common compromise.
What if the scan finds nothing?
That means the checks you configured passed on the routes covered. It is not proof of safety, so keep authorization tests and periodic review.
Safeguard policies and gates can block pull requests that break your rules, and the free scan at gold.safeguard.sh/scan is an easy first check.
Sources
- OWASP Authorization Testing Automation Cheat Sheet
- ZAP API Scan
- OWASP API1:2023 Broken Object Level Authorization
Last reviewed: 19 October 2026.
