Report

---
name: report
description: Use when one or more websec detection skills have produced results files and a single consolidated, severity-ranked security report is needed, or when asked to summarise or prioritise security findings across classes.
---

# Consolidated Security Report

## Overview
Detection skills each write `<output_dir>/<skill>-results.md`. This skill reads all of them, assigns severity, sorts, and produces two artefacts: `final-report.md` for people and `findings.json` for tooling. It preserves every finding's content verbatim — it ranks and arranges, it does not rewrite.

## Prerequisites
- Policy: `${CLAUDE_PLUGIN_ROOT}/references/policy.default.yaml`, then `.websec/policy.yaml` if present, merged per `${CLAUDE_PLUGIN_ROOT}/references/policy.md`. You need `output_dir`, `severity.overrides`, `severity.fail_threshold`, `report.include_not_vulnerable`, and `limits.*` so you can say which ceilings were reached.
- Contracts: `${CLAUDE_PLUGIN_ROOT}/references/severity-defaults.md` (tiers, defaults, adjustments, tiebreaker) and `${CLAUDE_PLUGIN_ROOT}/references/finding-template.md` (field names for JSON).
- `<output_dir>/architecture.md` if present — for project name and data-sensitivity context, and for its record of which controls are enforced outside the reviewed tree. If its `generated-from` stamp is `no-vcs` or `unknown`, note in the report that the architecture document's freshness could not be verified.
- At least one `<output_dir>/*-results.md`. If none exist, say so and stop.

## Procedure (in-session, no subagents)

### 1. Discover
List `<output_dir>/*-results.md`. The skill name is the filename prefix. Record which of the 33 detection skills have results and which do not:
`access-control api authentication business-logic clickjacking cors crypto csrf deserialization dom-based file-upload graphql host-header information-disclosure jwt llm nosql-injection oauth open-redirect os-command-injection path-traversal prototype-pollution race-conditions request-smuggling secrets sql-injection ssrf ssti web-cache-deception web-cache-poisoning websockets xss xxe`

### 2. Extract
From each results file take every finding block. Include `VULNERABLE` and `LIKELY VULNERABLE` in the report body. Count `NOT VULNERABLE` and `NEEDS MANUAL REVIEW`; include `NOT VULNERABLE` blocks in an appendix only if `report.include_not_vulnerable` is true. Always list `NEEDS MANUAL REVIEW` items in a short appendix table (title, file, uncertainty) — they are work for a human. Keep every field's text exactly as written.

### 3. Assign severity
For each included finding: start from the class default in `severity-defaults.md`; apply `severity.overrides[<skill>]` if set; then apply the adjustment rules using the finding's Impact and the sensitive-data section of `architecture.md`. Write a one-sentence **Severity rationale** per finding. Mark `LIKELY VULNERABLE` titles with "⚠ Likely".

### 4. Sort
Critical → High → Medium → Low; within a tier by confidentiality impact descending, then by number of affected locations. Findings that are the same flaw across many locations stay separate but adjacent.

### 5. Write `<output_dir>/final-report.md`

```markdown
# Security Review Report — <project>
**Generated**: <date> · **Detectors run**: <list> · **Not run**: <list>

## Gate
<only if severity.fail_threshold is set:> Threshold: <tier> → **PASS** | **FAIL** (<n> finding(s) at or above threshold). Informational only.

## Executive summary
| Severity | Count |
|---|---|
| Critical | n | High | n | Medium | n | Low | n | **Total** | **n** |
Needs manual review: n · Not vulnerable (counted): n · **Not verified (ceiling reached): n**

## Index
| # | Title | Detector | Severity | Location |

## Findings
### Critical
#### <n>. <Title> — <detector>
- **Classification**: VULNERABLE | LIKELY VULNERABLE
- **Severity rationale**: …
<all fields from the finding block, verbatim: File, Endpoint, Issue, Impact, Proof, Remediation, Dynamic Test, Confidence>
### High … ### Medium … ### Low  (omit empty tiers)

## Needs manual review
| Title | Detector | File | Uncertainty |

## Also observed / Suspicious instructions
<merged from results files, or "none">

## Coverage
| Detector | Results file | Candidates | Verified | Not verified | Status |
<one row per detector: Completed / Not run / Completed (capped). Fill Candidates, Verified and
 Not verified from each results file's Executive Summary; use 0 where the detector reported none.>

<if any detector was capped:> **Coverage is partial.** N candidates across M detectors were not
verified because `limits.max_candidates_per_detector` was reached. They are listed per detector in
the results files under "Not verified". Raise the ceiling or narrow the scope with `ignore_paths`
and run those detectors again before treating this report as complete.
```

### 6. Write `<output_dir>/findings.json`
An array of objects with exactly the fields in `finding-template.md`'s JSON table plus `severity` and `severity_rationale`. Include `NEEDS MANUAL REVIEW` items with `severity: null`. Valid JSON, UTF-8, no trailing commas.

## Reminders
- Do not shorten Proof, Remediation, or Dynamic Test. Long is fine; lossy is not.
- Severity is yours to assign; classification is the detector's — never change a classification here.
- Same flaw, five handlers → five findings, adjacent in the list.
- If a results file is malformed, include what can be parsed and add a line under Coverage: "Completed (parse issues: …)".
- The Gate line informs; it does not stop anything. Consumers decide what to do with it.
- Never present a capped run as a complete one. If any detector hit a ceiling, the partial-coverage note is required, and the Gate line — if set — must say it was computed over verified candidates only.