ZAP Triage
Use this skill after an authorized OWASP ZAP scan has produced JSON output. It is intentionally generic: it can be used with Rust, Rails, Django, Node, Go, Java, or any other web stack as long as the report and source code are available.
Safety Boundary
- Treat ZAP as evidence collection, not proof by itself.
- Do not run active scans unless the user gives an explicit target and authorization scope.
- Do not expand the scan scope from the report on your own.
- Do not apply fixes unless the user asks for implementation after triage and the affected files are clear.
- Prefer reading generated summaries before loading large raw HTML reports.
Workflow
- Confirm the ZAP report path, application root, target URL, and scan authorization scope.
- Prefer a compact summary. If only raw JSON exists, summarize alert, risk, route, parameter, evidence, and instance count.
- Group findings by route, risk, parameter, and likely code owner.
- Map each High and Medium finding to source files, handler/controller/action names, and line numbers when possible.
- For each finding, identify the vulnerable implementation pattern:
- reflected output without context-aware escaping
- SQL or query string concatenation
- user-controlled filesystem path
- missing shared response headers
- missing or weak CSRF/session handling
- authentication or authorization logic issue
- scan configuration or authentication coverage gap
- Propose the smallest safe remediation:
- escape at the output boundary
- use prepared statements or query builder parameters
- use allow lists or canonical path containment
- move headers into middleware or shared response code
- add server-side CSRF/session token validation
- add targeted authorization checks
- Classify each item as:
- confirmed
- likely true positive, needs manual reproduction
- likely false positive
- scan configuration issue
- Recommend the smallest verification command for each confirmed item.
- When implementation is requested, keep patches finding-scoped and preserve unrelated behavior.
Output
Return a compact triage report:
# ZAP triage
## Confirmed
| Risk | Alert | Route | Source | Recommended fix |
| --- | --- | --- | --- | --- |
## Fix Pattern
| Pattern | Vulnerable code shape | Safer code shape |
| --- | --- | --- |
## Needs Manual Check
| Risk | Alert | Why | Next command |
| --- | --- | --- | --- |
## Scan Notes
- Scope:
- Report:
- Exclusions or skipped rules:
- Residual risk:
- Follow-up scan:
Reusable Prompt
Use this prompt shape when invoking the skill manually:
Use zap-triage.
Report: <path-to-zap-json-or-summary>
Application root: <path>
Target URL: <authorized-url>
Task: map High and Medium findings to source code and propose minimal remediations.
Do not run active scans unless I explicitly ask.
1---2name: zap-triage3description: Turn OWASP ZAP JSON reports into code-level remediation work for any authorized web application without launching unscoped scans.4---56# ZAP Triage78Use this skill after an authorized OWASP ZAP scan has produced JSON output. It is intentionally generic: it can be used with Rust, Rails, Django, Node, Go, Java, or any other web stack as long as the report and source code are available.910## Safety Boundary1112- Treat ZAP as evidence collection, not proof by itself.13- Do not run active scans unless the user gives an explicit target and authorization scope.14- Do not expand the scan scope from the report on your own.15- Do not apply fixes unless the user asks for implementation after triage and the affected files are clear.16- Prefer reading generated summaries before loading large raw HTML reports.1718## Workflow19201. Confirm the ZAP report path, application root, target URL, and scan authorization scope.212. Prefer a compact summary. If only raw JSON exists, summarize alert, risk, route, parameter, evidence, and instance count.223. Group findings by route, risk, parameter, and likely code owner.234. Map each High and Medium finding to source files, handler/controller/action names, and line numbers when possible.245. For each finding, identify the vulnerable implementation pattern:25 - reflected output without context-aware escaping26 - SQL or query string concatenation27 - user-controlled filesystem path28 - missing shared response headers29 - missing or weak CSRF/session handling30 - authentication or authorization logic issue31 - scan configuration or authentication coverage gap326. Propose the smallest safe remediation:33 - escape at the output boundary34 - use prepared statements or query builder parameters35 - use allow lists or canonical path containment36 - move headers into middleware or shared response code37 - add server-side CSRF/session token validation38 - add targeted authorization checks397. Classify each item as:40 - confirmed41 - likely true positive, needs manual reproduction42 - likely false positive43 - scan configuration issue448. Recommend the smallest verification command for each confirmed item.459. When implementation is requested, keep patches finding-scoped and preserve unrelated behavior.4647## Output4849Return a compact triage report:5051```markdown52# ZAP triage5354## Confirmed5556| Risk | Alert | Route | Source | Recommended fix |57| --- | --- | --- | --- | --- |5859## Fix Pattern6061| Pattern | Vulnerable code shape | Safer code shape |62| --- | --- | --- |6364## Needs Manual Check6566| Risk | Alert | Why | Next command |67| --- | --- | --- | --- |6869## Scan Notes7071- Scope:72- Report:73- Exclusions or skipped rules:74- Residual risk:75- Follow-up scan:76```7778## Reusable Prompt7980Use this prompt shape when invoking the skill manually:8182```text83Use zap-triage.84Report: <path-to-zap-json-or-summary>85Application root: <path>86Target URL: <authorized-url>87Task: map High and Medium findings to source code and propose minimal remediations.88Do not run active scans unless I explicitly ask.89```