how to run an OWASP ZAP scan in CI

TL;DR

The fastest way to get ZAP into CI is the official baseline scan: it spiders your staging app and runs passive checks, which catches missing security headers, cookie flag issues, and other low-hanging fruit with no auth setup. Run the maintained Docker image or GitHub Action against a staging URL on every deploy to staging, fail the build on HIGH findings, and tune out false positives with an ignore rules file. Never point it at production without permission and rate-limit thoughtfulness.

how to run an OWASP ZAP scan in CI

Use this when

• Your pipeline has no dynamic security testing and you want the cheapest first step
• A compliance checklist asks for DAST or periodic vulnerability scanning
• You want a security gate before promoting staging to production
• You inherited an app and want a quick external view of its obvious holes

Not for

• Static code analysis (use Semgrep or similar; different skill)
• Authenticated deep scans of complex SPAs (start with baseline, graduate later)
• Scanning production or third-party sites you dont own

Steps

1. Pick a scan target you own. Use a staging or preview environment that mirrors production, seeded with test data. Confirm you have written permission to scan it; scanning anything else is out of scope.

Expected output: a stable staging URL that your CI can reach and that you are authorized to test.

1. Add the baseline scan to your pipeline. The official ZAP GitHub Action (zaproxy/action-baseline) or the stable Docker image both work; point it at your staging URL and let it spider for a few minutes. Run it on pushes to main and on a nightly schedule, not on every tiny PR, to keep build times sane at first.

Expected output: the CI job runs ZAP, spiders the app, and produces an HTML/Markdown report artifact.

1. Fail the build on HIGH, warn on MEDIUM. Configure the action's fail threshold so HIGH-severity findings break the build while MEDIUMs are reported but non-blocking at first. Tighten to MEDIUM once the baseline is clean.

Expected output: introducing a missing HSTS header or an exposed debug endpoint fails the pipeline.

1. Tune false positives with ignore rules. ZAP flags things like missing headers on purpose-built endpoints; add them to the baseline ignore file with a comment explaining why each is safe, and review the file quarterly.

Expected output: the ignore file is short, each entry has a justification, and reruns stay green.

1. Graduate to the full scan for releases. The full (active) scan attacks parameters and forms, so it is slower and noisier; run it nightly or pre-release against staging, never as a blocking step on every commit until you trust its signal.

Expected output: a nightly active-scan report with findings triaged the next morning.

1. Track findings over time. Save reports as CI artifacts, open tickets for real findings with the ZAP evidence attached, and watch the count trend down. A scan nobody reads is theater.

Expected output: a month of reports showing the HIGH count at zero and MEDIUMs shrinking.

Variant phrasings

• "OWASP ZAP GitHub Actions example"
• "ZAP baseline vs full scan difference"
• "add DAST scan to GitLab CI"
• "automated web app vulnerability scan in pipeline"

Edge cases and pitfalls

• Baseline scans dont log in, so anything behind auth is invisible; add ZAP authentication config or accept the coverage gap consciously.
• Active scans can create junk data, send emails, or trigger rate limits; run them against staging with test data and tell the team when they run.
• Spider coverage of heavy SPAs is weak; pair ZAP with an authenticated API scan or a recorded user journey for real coverage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3P1g0crzGhwtqSWgZ2GkUQ