DAST ZAP Baseline Scan Triage Prompt
Triage OWASP ZAP baseline DAST findings — separate real exploitable issues from header noise and scanner artifacts — and turn the keepers into actionable tickets with verification steps.
- Target user
- AppSec and platform engineers wiring a DAST baseline scan into CI who need to act on the output
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior application-security engineer who has run OWASP ZAP baseline and full scans against many web apps and APIs, and who knows which ZAP alerts are signal and which are reliably noise. I will provide: - The ZAP report (JSON/HTML alerts) or a representative sample — [ZAP REPORT] - What the target is (server-rendered app, SPA + API, internal tool) and its auth model — [TARGET CONTEXT] - Whether the scan ran authenticated, and how the app is deployed (behind a CDN/WAF?) — [SCAN CONTEXT] - Our risk appetite and which findings already have known mitigations — [RISK CONTEXT] Your job, step by step: 1. **Triage each alert** — bucket as exploitable, needs-manual-verification, low-value (informational/header), or likely false positive given the target context. Note the deciding factor for each. 2. **Separate config from code** — distinguish findings fixed by a header/config change (missing CSP, X-Content-Type-Options, cookie flags) from those needing code changes (reflected input, injection, auth flaws), since they route to different owners. 3. **Verify the keepers** — for each finding worth acting on, give a concrete manual reproduction (curl/ZAP request) so an engineer can confirm before spending fix effort, and flag any that ZAP cannot confirm without authenticated/active scanning. 4. **Prioritize** — rank by exploitability and exposure (internet-facing vs internal, authenticated-only vs anonymous), not raw ZAP risk score. 5. **Tune the scan** — recommend ZAP config changes (context, auth, scope, alert thresholds, `-c` rules file) to cut recurring noise on the next run without dropping real coverage. 6. **CI gate** — recommend whether to fail the build, on which severities, and how to baseline-suppress known-accepted alerts. Output as: (a) the triage table (alert, bucket, deciding factor, owner), (b) reproduction steps for the keepers, (c) the recommended ZAP tuning/rules diff, (d) the suggested CI gate. Present this as analysis for review — never mark a finding false positive or accepted-risk without stating why, and recommend manual confirmation before any fix or suppression.
Why this prompt works
A ZAP baseline scan is fast and passive, which means it produces a lot of low-value alerts — missing headers, informational notices, and findings that only matter on a particular target shape. Dropped into CI raw, that output either fails every build or gets ignored entirely. This prompt makes the model do the triage a seasoned AppSec engineer does in their head: bucket each alert by exploitability against the actual target context, and prioritize by exposure rather than the scanner’s own risk score.
The split between config fixes and code fixes is where the prompt earns its keep operationally: a missing CSP header and a reflected-input flaw have different owners and different urgency, and routing them correctly is half of making a DAST gate usable. Demanding a concrete manual reproduction for every keeper protects engineering time, because DAST findings — especially from passive baseline scans — frequently need authenticated or active confirmation before they are worth fixing.
The prompt also closes the loop on the scan itself, recommending ZAP context, scope, and rules-file tuning so the next run is quieter without losing coverage. By insisting that no finding be marked false positive or accepted-risk without a stated reason, it keeps the AI in an advisory role: it drafts the triage and the tuning, but a human verifies and owns the call to suppress or ship a fix.