pentest-review

name	pentest-review
description	Review and triage pentest scan results. Use when the user says 'review pentest', 'check scan results', 'what failed', 'pentest findings', or 'triage results'.
user-invocable	true
argument-hint	[target-name]
allowed-tools	Read, Grep, Glob, Bash, Agent
effort	high

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Purpose

Read existing pentest reports and produce classified findings with actionable triage.

Workflow

Phase 1: Locate Report

1. Determine target name from arguments (default: rockport)
2. Find the latest report directory: pentest/reports/<target>/<timestamp>/
3. If no reports exist, tell the user to run /pentest <target> first

Phase 2: Quick Triage

Use jq on results.json to extract:

• Module summary: status, pass/fail/skip counts, duration per module
• Total findings by tag (PASS, FAIL, WARN, LEAK, VULN, SKIP, INFO, FOUND, OK)
• Auth bootstrap status
• Skipped modules and reasons

Do NOT read entire module output files. Use jq queries on results.json for the summary view.

Also check auth-bootstrap.log for auth setup issues — failed auth bootstrap is a common reason for module skips/failures.

Fallback: if results.json is missing, grep module output files in modules/ for tagged lines.

Phase 3: Deep Read (findings only)

For modules that have failures (FAIL, WARN, LEAK, VULN, FOUND):

• Read only those module output files from modules/<module>.txt
• Use a subagent for large files to keep main context clean

For modules that passed or were skipped, do NOT read their output files.

Phase 4: Classification

Cross-reference each finding against pentest/targets/rockport.yaml:

Classification	Criteria
NEW	Not in known_risks or false_positives
CONFIRMED	Matches a known_risks entry with status: present or status: accepted
REGRESSION	Matches a known_risks entry with status: fixed
FALSE POSITIVE	Matches false_positives list or explained by architecture
INCONCLUSIVE	Rate limiting (429) or other interference prevented proper testing

Phase 5: Diagnose Skips

For each skipped test, explain why:

• Missing tool (e.g., ffuf, testssl.sh) → suggest pentest/install.sh
• Missing auth (no API key, no CF-Access) → suggest checking terraform output
• Rate limited → suggest lower --rate value
• Sidecar unreachable → suggest checking deployment status

Phase 6: Detect Issues

Check for signs of interrupted or incomplete scans:

• Missing modules in results.json that should have run
• Zero findings in a module that normally produces many
• Very short duration (<1s) for modules that normally take longer

Output Format

## Pentest Review: <target>

**Report**: <timestamp>
**Modules**: N run, N passed, N failed, N skipped

### Findings Summary

| Module | Status | Pass | Fail | Skip | New Findings |
|--------|--------|------|------|------|-------------|
| ...    | ...    | ...  | ...  | ...  | ...         |

### Critical Findings (NEW or REGRESSION)

- [FAIL] (module) Description — **NEW**
- [WARN] (module) Description — **REGRESSION**

### Confirmed Known Risks

- [FAIL] (module) Description — matches known_risk: <id>

### False Positives

- [FAIL] (module) Description — matches false_positive: <reason>

### Skipped Tests

- (module) Reason — Remediation: ...

### Recommendations

1. ...
2. ...

Rules

• Never read paths-common.json or large tool artifact files in full — use head or wc -l to check size first
• Use subagents for modules with >50 findings
• Distinguish between pentest infrastructure bugs (script errors) and target security findings
• Do not re-run scans — only review existing reports