# Lisa Security Zap Scan

> Run an OWASP ZAP baseline security scan locally using Docker. Checks for the ZAP baseline script, executes the scan, and summarizes findings by risk level with remediation recommendations.

- Skill: `codyswanngt/lisa-security-zap-scan` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add codyswanngt/lisa-security-zap-scan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-security-zap-scan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: codyswanngt (https://skillmd.com/u/codyswanngt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/codyswanngt/lisa-security-zap-scan

---


# OWASP ZAP Baseline Security Scan

Run a ZAP baseline security scan against the local application.

## Workflow

1. **Check prerequisites**:
   - Verify Docker is installed and running: `docker info`
   - Check if `scripts/zap-baseline.sh` exists in the project

2. **Execute scan**:
   - If the script exists, run: `bash scripts/zap-baseline.sh`
   - If the script does not exist, inform the user that this project does not have a ZAP baseline scan configured

3. **Analyze results**:
   - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
   - Summarize findings:
     - Total number of alerts by risk level (High, Medium, Low, Informational)
     - **Every alert reaches classification** -- High, Medium, Low, and Informational alike. Risk
       level orders the summary; it never filters it. **Nothing is dropped before classification**,
       so no alert can leave the report unclassified. Medium+ alerts are listed first, in full (rule
       ID, name, recommended fix); Low/Informational alerts are still listed, bucketed, and given a
       `reason`, even when compressed to one line each.
     - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)

4. **Apply the impact-or-exploitability bar** -- the same bar the `lisa-security-review` skill
   defines; follow that skill, do not restate it. A ZAP alert is not a reproducer by itself: the
   alert names a pattern, not an exercised impact path.
   - **Security (proven)** -- the alert carries a reproducer **and** a bounded impact statement. The
     reproducer counts only if its evidence kind **reaches the claim's boundary** under the
     `claim-evidence-mapping` contract (BCE-1, #1835): a ZAP request/response transcript is an
     `http-transcript` and reaches the `http-api` boundary only. An alert whose claim is about
     rendered UI (`browser`) or persisted state (`data`) needs evidence at *that* boundary -- a
     transcript never proves it.
   - **Security (unproven)** -- everything else, each with a one-line `reason` (typically
     "alert only, no reproducer / no bounded impact", or "transcript does not reach the claim's
     boundary"). Unproven alerts are **not dropped** and not demoted out of the security summary --
     they render in the unproven bucket so a reader still sees them.
   - Rename the unproven heading only if `security.review.unprovenBucket` is set to something other
     than `security-unproven`; no other classification changes.

5. **Handle failures**:
   - If the scan failed, explain what failed and suggest concrete remediation steps

## Execution

Run the scan now.