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

# 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.