/report-template

name: report-template
description: "Autonomous report generation from collected findings. Produces bug bounty submissions, client deliverables, and vulnerability reports using the standard finding schema."
when_to_use: "Use when asked to generate, write, or submit a report — bug-bounty submissions, client deliverables, or vulnerability reports — from collected findings using the standard finding schema."

Report Template

> Sub-skill of `offensive-osint`. Load `osint-methodology` for pipeline and deliverable context. > Authorized targets only.

---

BEHAVIORAL CONTRACT

**When triggered:** Report generation, bug bounty submission, vulnerability write-up, or client deliverable creation is needed.

**Execute:**

1. Collect all findings from the current engagement — pull from sidecar JSON files if available (`analysis-and-reporting` §6). 2. For bug bounty submissions: populate the Bug Bounty Report Template (§1) for each finding. 3. For client deliverables: populate the Client Report Template (§2) covering all findings. 4. Auto-fill severity, confidence, and attack-path hints from `analysis-and-reporting` §4 and §3. 5. Include reproduction steps with evidence (URL + UTC timestamp + SHA-256). 6. Apply risk translation for executive audience (see `osint-methodology` §14).

**Output:** Completed report per §1 or §2 template, ready for submission or delivery.

**Severity rules:** Use severity from the finding schema. Include CVSS v3 vector + score for bug bounty.

**Gating rules:** Never include raw credentials in reports — truncate to last 4 characters. Redact PII. Include encrypted credential bundle separately if needed.

**Chain to:** This is typically the final skill in the pipeline. Receives findings from all other sub-skills via `analysis-and-reporting` sidecar coordination.

---

1. Bug Bounty Report Template

Title: [{severity}] [{component}] {brief description}

## Overview
**Vulnerability Type:** {e.g., XSS, CSRF, SQL Injection, Exposed Credentials, Misconfiguration}

## Description
{2-3 sentences: what the vulnerability is and why it matters}

## Steps To Reproduce
1. {step with exact URL/endpoint}
2. {step with payload or action}
3. {step showing the result}
4. {additional steps as needed}

## Proof of Concept
{The most important section. Sanitized HTTP request/response, screenshot, or command output.
 Include: URL + UTC timestamp + tool used. Truncate secrets to last 4 chars.}

## Impact
{What data/users/functions are at risk. Business-language impact statement.}

## Severity
{CVSS v3 vector + score + 1-sentence justification}

## Suggested Fix
{Concrete, actionable remediation recommendation}

## Supporting Material
{Screenshots, logs, WARC archives, SHA-256 hashes of downloaded artifacts}

## Additional Information
{Engagement context, related findings, references (CVE IDs, advisory URLs)}

**Platform notes:**

• HackerOne: CVSS-based severity
• Bugcrowd: VRT taxonomy (P1–P5)
• Intigriti / YesWeHack: Similar to HackerOne
• Unprogrammed targets: check `/.well-known/security.txt` → `security@<target>` → WHOIS abuse contact → CERT/CC. 90-day disclosure window.

---

2. Client Report Template

# Engagement Report: {target} — {date range}

## Executive Summary
- Engagement type: {red team / bug bounty / ASM / ad-hoc}
- Scope: {domains, IP ranges, applications}
- Duration: {start — end}
- Top findings: {3-5 highest-severity findings with business impact + remediation effort}

## Aggregate Metrics
- Total assets discovered: {count by type}
- Findings by severity: {CRITICAL: N, HIGH: N, MEDIUM: N, LOW: N, INFO: N}
- Live credentials confirmed: {count}

## Findings

### Finding {N}: {title}
- **ID:** {stable hash or UUID}
- **Severity:** {CRITICAL/HIGH/MEDIUM/LOW/INFO}
- **Confidence:** {TENTATIVE/FIRM/CONFIRMED}
- **Asset:** {typed key, e.g., sub:api.example.com}
- **Category:** {e.g., SECRET_LEAK, OPEN_GRAPHQL_API, SSO_EXPOSURE}
- **Discovered:** {UTC ISO8601}
- **Description:** {2-5 sentences}
- **Evidence:** {URL + tool + screenshot + raw HTTP (truncated 2 KiB) + SHA-256}
- **Reproduction steps:** {numbered, copy-pasteable}
- **Business impact:** {risk translation for non-technical audience}
- **Remediation:** {immediate / short-term / long-term}
- **Attack path hint:** {from analysis-and-reporting §3 templates}
- **References:** {CVE-ID, advisory URL, vendor doc}

{Repeat for each finding}

## Recommended Next Steps
{Timeline-based recommendations with priority}

## Reproduction Package
- `run-log.jsonl` — timestamped event log
- `assets.db` — discovered assets
- `findings.db` — all findings
- `evidence/` — screenshots, HTTP captures, downloads (with .sha256)
- `re-test-script.sh` — re-validation script for remediated findings

Structured Outrider run contract

Follow the shared run-contract instructions in `../_shared/run-contract.md`.

• Contract skill identifier: `report-template`.
• Consume `skill_request` version 1 and produce `skill_result` version 1 when participating in an Outrider run.
• Use evidence IDs for all claims; do not cite unregistered local paths as claim evidence.
• Discoveries are observations and do not expand scope or approval.
• Do not claim final finding validation; use `finding_candidate` only when a human-reviewed candidate should be handed off.
• Do not directly edit `manifest.json`, `scope.yaml`, `run.jsonl`, `evidence.jsonl`, or `approvals.jsonl`.
• Use policy-gated MCP with the explicit `run_dir`; the Python control layer and MCP boundary must reevaluate current controls.

Promoted finding source

Promoted findings are read from the append-only `findings.jsonl` registry. Unpromoted `finding_candidate` claims from skill results must be clearly labeled as candidates, and report generation must not silently promote them. In this PR, `findings.md` remains operator-managed working Markdown rather than an automatically rendered finding export.