rtexit-method 0.1.0 → 0.1.2

package/packaged-assets/.agents/skills/rt-technical-report/SKILL.md

@@ -0,0 +1,710 @@
+---
+name: rt-technical-report
+description: "Generate complete technical penetration testing report for security engineers. Includes: engagement details, methodology, findings summary table, detailed findings (one section per finding), attack chain diagrams, MITRE ATT&CK coverage, technical remediation steps, and appendices (tool output, PoC code, compliance mapping). Professional quality for client delivery."
+---
+
+# rt-technical-report — Technical Penetration Testing Report Generator
+
+## Overview
+
+This skill produces the complete technical report artifact that is delivered to the client's security engineering team at the end of an engagement. It is the last required step before engagement close and is the primary deliverable that justifies every hour logged.
+
+The technical report is distinct from the executive report (which is audience-targeted at C-suite). This document is written for the people who will actually fix the findings: developers, security engineers, DevOps leads, and system administrators. It must be reproducible, evidence-backed, and actionable at the command-line level.
+
+### Where This Skill Fits in the Engagement Lifecycle
+
+```
+1. Scope Definition (rt-scope-definition)
+2. Reconnaissance     (rt-active-recon, rt-osint, rt-subdomain-enum)
+3. Exploitation       (rt-exploit-*, rt-lateral-movement)
+4. Post-Exploitation  (rt-post-exploitation, rt-credential-hunt)
+   ↓
+5. FINDINGS DOCUMENTED (rt-agent-scribe → FD per finding)
+   ↓
+6. THIS SKILL: rt-technical-report  ← you are here
+   ↓
+7. Executive summary attached (rt-agent-scribe → ER)
+8. Client delivery
+```
+
+This skill should not be run until all findings are confirmed, documented in finding MD files, and present in `findings-master.csv`. Running it early produces an incomplete report.
+
+---
+
+## Prerequisites Checklist
+
+Before generating the report, verify the following are true:
+
+- [ ] All findings are in `_rtexit-output/docs/findings/findings-master.csv` with status `CONFIRMED`
+- [ ] Each finding has a corresponding `F-NNN.md` file with Description, Evidence, and Reproduction Steps filled in
+- [ ] `_rtexit-output/docs/engagement/scope.md` exists and is complete
+- [ ] `_rtexit-output/docs/engagement/engagement-info.json` has `ref`, `client`, `start`, and `methodology` set
+- [ ] `_rtexit-output/docs/engagement/timeline.md` has entries covering the full engagement period
+- [ ] At least one MITRE ATT&CK technique is mapped per finding
+- [ ] Chain of custody is logged for all critical and high severity evidence
+
+---
+
+## Step-by-Step Workflow
+
+### Step 1 — Pull Current Finding State
+
+Run the finding tracker to get a full picture of what will be included in the report:
+
+```bash
+python3 {project-root}/_rtexit/scripts/finding_tracker.py stats
+python3 {project-root}/_rtexit/scripts/finding_tracker.py list
+python3 {project-root}/_rtexit/scripts/finding_tracker.py export --format md
+```
+
+Expected output before starting:
+
+```
+=== Finding Statistics ===
+🔴 CRITICAL  :   2  ██
+🟠 HIGH      :   5  █████
+🟡 MEDIUM    :   4  ████
+🔵 LOW       :   3  ███
+⚪ INFO      :   1  █
+
+   TOTAL    : 15
+```
+
+If findings are missing or their CVSS/MITRE fields are empty, stop and complete those finding files first.
+
+### Step 2 — Assemble Engagement Metadata
+
+Read these files to populate report headers:
+
+- `_rtexit-output/docs/engagement/engagement-info.json` — ref, client, dates, methodology, scope type
+- `_rtexit-output/docs/engagement/scope.md` — in-scope targets and exclusions
+- `_rtexit-output/docs/engagement/timeline.md` — engagement activity log
+
+### Step 3 — Build the Report Structure
+
+Compose the report in the following fixed order. Do not skip or reorder sections. Each section has specific content requirements described below.
+
+```
+1.  Cover Page
+2.  Document Control
+3.  Table of Contents
+4.  Executive Summary (brief — 1 paragraph for engineers)
+5.  Engagement Details
+6.  Scope & Rules of Engagement
+7.  Methodology
+8.  Findings Summary Table
+9.  Detailed Findings (one full section per finding, CRITICAL first)
+10. Attack Chain Diagrams
+11. MITRE ATT&CK Coverage Matrix
+12. Remediation Roadmap
+13. Appendix A — Tool Output Excerpts
+14. Appendix B — Proof-of-Concept Code
+15. Appendix C — Compliance Mapping
+16. Appendix D — Glossary
+```
+
+### Step 4 — Write Each Finding Section
+
+For every finding in severity order (CRITICAL → HIGH → MEDIUM → LOW → INFO), produce a full section using the finding template in this skill. Do not summarize or abbreviate findings that are CRITICAL or HIGH severity.
+
+Each finding section must include:
+- Finding ID, title, severity badge, CVSS score and vector string
+- One-paragraph description (what is it, why does it exist)
+- Business impact statement (what an attacker can do, in business terms)
+- Exact reproduction steps (copy-paste ready)
+- Evidence block (actual command output, HTTP request/response, or screenshot reference)
+- MITRE ATT&CK technique mapping with tactic and technique name
+- Remediation: immediate action, short-term fix, long-term fix
+- References (CVE if applicable, CWE, vendor advisory)
+
+### Step 5 — Draw Attack Chain Diagrams
+
+For any finding that was part of a multi-step attack chain (e.g., SSRF used to reach internal Redis, then credential exfiltration), draw a Mermaid diagram. Include one diagram per distinct attack path.
+
+### Step 6 — Build MITRE ATT&CK Coverage Table
+
+Aggregate all MITRE ATT&CK techniques from finding MD files. Group by tactic. Show which findings map to each technique.
+
+### Step 7 — Write Remediation Roadmap
+
+Order all remediations by risk priority (CVSS score descending). Group into three tracks: immediate (0–7 days), short-term (8–30 days), long-term (31–90 days). Include effort estimate (hours) and responsible party for each item.
+
+### Step 8 — Populate Appendices
+
+**Appendix A** — Copy key tool output excerpts from terminal logs in `_rtexit-output/docs/evidence/terminal-logs/`. Include only the most probative output for each finding (not full verbose logs).
+
+**Appendix B** — Include all PoC code written during the engagement. Each PoC should have: finding reference, language, description, code block, and expected output.
+
+**Appendix C** — Pull compliance mapping from the finding MD files. Produce a table showing which findings violate which controls across PCI-DSS, GDPR, and ISO 27001.
+
+### Step 9 — Log Report Generation
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-technical-report \
+  --phase reporting \
+  --note "Technical report generated — {finding_count} findings"
+```
+
+Save the report to:
+`_rtexit-output/docs/reports/technical-report-{engagement_ref}.md`
+
+---
+
+## Report Templates
+
+### Cover Page
+
+```markdown
+---
+CONFIDENTIAL — RESTRICTED DISTRIBUTION
+---
+
+# Penetration Testing Technical Report
+
+**Client:** Meridian Financial Services Ltd.
+**Engagement Reference:** MFS-RT-WEB-2026-003
+**Report Version:** 1.0
+**Report Date:** 2026-05-31
+**Classification:** Confidential — For Security Team Use Only
+**Prepared By:** Red Team Operations
+**Operator:** Ahmed Al-Rashidi | m.hegazy@elunic.net
+
+---
+
+**Distribution List:**
+- CISO: Hassan Al-Mansoori
+- Head of Security Engineering: Dina Khalifa
+- DevOps Lead: Tariq Yousef
+
+**Do not forward this document outside the distribution list without written authorization.**
+```
+
+### Document Control
+
+```markdown
+## Document Control
+
+| Version | Date       | Author          | Changes                        |
+|---------|------------|-----------------|--------------------------------|
+| 0.1     | 2026-05-20 | Ahmed Al-Rashidi | Initial draft — findings draft  |
+| 0.2     | 2026-05-28 | Ahmed Al-Rashidi | Evidence review complete        |
+| 1.0     | 2026-05-31 | Ahmed Al-Rashidi | Final delivery                  |
+
+**Engagement Period:** 2026-05-05 to 2026-05-24 (15 business days)
+**Testing Window:** 09:00–18:00 GST, Monday–Friday
+**Methodology:** PTES (Penetration Testing Execution Standard)
+**Scope Type:** Grey-box — application source code not provided; internal architecture diagrams shared
+```
+
+### Engagement Details Section
+
+```markdown
+## Engagement Details
+
+### Objectives
+
+This assessment was commissioned to evaluate the security posture of Meridian Financial Services' customer-facing web application (`portal.meridian-fs.com`) and its underlying API layer. The engagement simulated an external attacker with no prior credentials and an authenticated customer-level user, following a grey-box methodology.
+
+Primary objectives:
+1. Identify vulnerabilities that could lead to unauthorized access to customer financial data
+2. Assess the application's resilience against OWASP Top 10 attack classes
+3. Evaluate API endpoint authorization controls
+4. Test session management and authentication mechanisms
+
+### Engagement Team
+
+| Role               | Name              | Areas Covered                          |
+|--------------------|-------------------|----------------------------------------|
+| Lead Operator      | Ahmed Al-Rashidi  | API testing, authentication, SSRF      |
+| Web Specialist     | Karim Mansour     | Injection, XSS, file upload            |
+| Recon Specialist   | Nour Ibrahim      | OSINT, subdomain enum, infrastructure  |
+
+### Testing Environment
+
+- **Primary Target:** `https://portal.meridian-fs.com` (Production — read-only constraint applied)
+- **API Base:** `https://api.meridian-fs.com/v2`
+- **Admin Panel:** `https://portal.meridian-fs.com/admin` (out of scope for destructive testing)
+- **Mobile App:** Not in scope for this engagement
+- **Test Account Provided:** `testuser@meridian-test.com` (Customer tier, no admin rights)
+```
+
+### Findings Summary Table
+
+```markdown
+## Findings Summary
+
+| ID    | Severity   | CVSS  | Title                                          | Asset                           | Status    |
+|-------|-----------|-------|------------------------------------------------|---------------------------------|-----------|
+| F-001 | 🔴 CRITICAL | 9.8   | SQL Injection in Customer Search API           | api.meridian-fs.com/v2/search  | CONFIRMED |
+| F-002 | 🔴 CRITICAL | 9.1   | Authentication Bypass via JWT Algorithm Confusion | portal.meridian-fs.com/login | CONFIRMED |
+| F-003 | 🟠 HIGH    | 8.6   | SSRF in Document Export Function               | portal.meridian-fs.com/export  | CONFIRMED |
+| F-004 | 🟠 HIGH    | 8.1   | Insecure Direct Object Reference — Account Data | api.meridian-fs.com/v2/account | CONFIRMED |
+| F-005 | 🟠 HIGH    | 7.5   | Stored XSS in Transaction Comments             | portal.meridian-fs.com/txn     | CONFIRMED |
+| F-006 | 🟡 MEDIUM  | 6.5   | Verbose Error Messages Exposing Stack Traces   | api.meridian-fs.com            | CONFIRMED |
+| F-007 | 🟡 MEDIUM  | 5.8   | Missing Rate Limiting on Login Endpoint        | portal.meridian-fs.com/login   | CONFIRMED |
+| F-008 | 🔵 LOW     | 3.1   | Cookies Missing Secure and HttpOnly Flags      | portal.meridian-fs.com         | CONFIRMED |
+
+**Risk Summary:**
+- Critical: 2 | High: 3 | Medium: 2 | Low: 1 | Total: 8
+- Overall Risk Rating: **CRITICAL** — immediate remediation required before next production deployment
+```
+
+### Individual Finding Section Template (with example content)
+
+```markdown
+---
+
+## F-001 — SQL Injection in Customer Search API
+
+**Severity:** 🔴 CRITICAL
+**CVSS Score:** 9.8
+**CVSS Vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
+**CWE:** CWE-89 — Improper Neutralization of Special Elements used in an SQL Command
+**CVE:** N/A (configuration-specific)
+**MITRE ATT&CK:** T1190 — Exploit Public-Facing Application
+**Asset:** `https://api.meridian-fs.com/v2/customers/search`
+**Phase Discovered:** Exploitation (Day 3)
+**Date:** 2026-05-08
+
+### Description
+
+The customer search API endpoint at `/v2/customers/search` passes the `q` query parameter directly into a SQL query without sanitization or parameterized queries. An unauthenticated attacker can inject arbitrary SQL to read, modify, or delete data in the underlying PostgreSQL database, which stores all customer financial records.
+
+The vulnerability exists because the search handler concatenates user input directly into the query string:
+
+```python
+# Vulnerable code pattern (reconstructed from error messages)
+query = f"SELECT * FROM customers WHERE name LIKE '%{user_input}%'"
+```
+
+### Business Impact
+
+An unauthenticated attacker can exfiltrate the complete customer database, including names, account numbers, transaction histories, and hashed passwords. They can also modify account balances, delete records, or escalate to OS-level command execution via PostgreSQL's `COPY TO/FROM` or `pg_read_file` functions if the database user has elevated permissions.
+
+**Worst-case scenario:** Complete breach of all 47,000 customer records, regulatory fines under GDPR Article 83 (up to 4% of global annual turnover), and mandatory customer notification within 72 hours of discovery.
+
+### Reproduction Steps
+
+1. Identify the search endpoint:
+   ```
+   GET https://api.meridian-fs.com/v2/customers/search?q=ahmed
+   ```
+
+2. Confirm SQL injection with a single quote:
+   ```
+   GET https://api.meridian-fs.com/v2/customers/search?q=ahmed'
+   ```
+   Response: HTTP 500 with PostgreSQL error in body (evidence of unhandled exception).
+
+3. Extract database version with UNION injection:
+   ```
+   GET https://api.meridian-fs.com/v2/customers/search?q=ahmed' UNION SELECT version(),null,null,null,null--
+   ```
+
+4. Enumerate tables:
+   ```
+   GET /v2/customers/search?q=' UNION SELECT table_name,null,null,null,null FROM information_schema.tables WHERE table_schema='public'--
+   ```
+
+5. Dump customer records (limited to 5 rows for PoC):
+   ```
+   GET /v2/customers/search?q=' UNION SELECT id,email,account_number,balance,password_hash FROM customers LIMIT 5--
+   ```
+
+6. Automated extraction using sqlmap (engagement-authorized):
+   ```bash
+   sqlmap -u "https://api.meridian-fs.com/v2/customers/search?q=test" \
+     --dbms=postgresql \
+     --level=3 \
+     --risk=2 \
+     --dump -T customers \
+     --batch
+   ```
+
+### Technical Evidence
+
+```
+HTTP Request:
+GET /v2/customers/search?q=ahmed'%20UNION%20SELECT%20version(),null,null,null,null-- HTTP/1.1
+Host: api.meridian-fs.com
+Authorization: (none)
+
+HTTP Response:
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "results": [
+    {
+      "id": "PostgreSQL 14.7 on x86_64-pc-linux-gnu, compiled by gcc 11.3.0, 64-bit",
+      "email": null,
+      "account_number": null,
+      "balance": null,
+      "name": null
+    }
+  ],
+  "count": 1
+}
+```
+
+Screenshot reference: `_rtexit-output/docs/evidence/screenshots/F-001-sqli-version-dump.png`
+Terminal log: `_rtexit-output/docs/evidence/terminal-logs/20260508_rt-exploit-api_*.txt`
+
+### MITRE ATT&CK Mapping
+
+| Tactic              | Technique                          | ID    |
+|---------------------|------------------------------------|-------|
+| Initial Access      | Exploit Public-Facing Application  | T1190 |
+| Collection          | Data from Information Repositories | T1213 |
+| Exfiltration        | Exfiltration Over C2 Channel       | T1041 |
+
+### Remediation
+
+#### Immediate (0–7 days)
+- Deploy a WAF rule blocking SQL metacharacters (`'`, `--`, `UNION`, `SELECT`) in the `q` parameter as a temporary control.
+- Restrict the database user used by the API to `SELECT` only on the `customers` table. Remove any `COPY`, `pg_read_file`, or superuser privileges.
+- Enable PostgreSQL query logging and alert on error rate spikes.
+
+#### Short-term (8–30 days)
+- Rewrite all database queries in the application to use parameterized queries or prepared statements:
+  ```python
+  # Secure pattern
+  cursor.execute("SELECT * FROM customers WHERE name LIKE %s", (f"%{user_input}%",))
+  ```
+- Conduct a full code review of all database-touching functions using a SAST tool (e.g., Semgrep rule `python.lang.security.audit.sqli`).
+- Implement input validation: reject inputs containing SQL keywords when used outside expected character classes.
+
+#### Long-term (31–90 days)
+- Adopt an ORM (SQLAlchemy, Django ORM) that abstracts raw SQL construction entirely.
+- Add SQL injection test cases to the CI/CD pipeline using DAST (OWASP ZAP or Nuclei templates).
+- Conduct developer training on secure query construction.
+
+### References
+
+- [CWE-89 — SQL Injection](https://cwe.mitre.org/data/definitions/89.html)
+- [OWASP — SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)
+- [MITRE ATT&CK T1190](https://attack.mitre.org/techniques/T1190/)
+- [PostgreSQL Security Hardening](https://www.postgresql.org/docs/current/security.html)
+```
+
+---
+
+## Attack Chain Diagram Template
+
+Use this for multi-step attack paths. Produce one diagram per distinct chain. Use Mermaid syntax.
+
+```markdown
+## Attack Chain: External Attacker to Customer Data Exfiltration
+
+The following diagram shows how findings F-001 and F-003 can be combined by an attacker starting with no credentials.
+
+```mermaid
+flowchart LR
+    A["External Attacker\n(No credentials)"]
+    B["F-007: No Rate Limiting\non /login\n→ Credential Stuffing"]
+    C["Low-privilege\nCustomer Session"]
+    D["F-003: SSRF via\n/export endpoint\n→ Probe internal network"]
+    E["Internal Metadata\nService 169.254.169.254\n→ AWS IAM credentials"]
+    F["F-001: SQLi via\n/v2/customers/search\n→ DB dump (unauthenticated)"]
+    G["47,000 Customer\nRecords Exfiltrated"]
+
+    A -->|"Step 1"| B
+    B -->|"Step 2"| C
+    C -->|"Step 3"| D
+    D -->|"Step 4"| E
+    A -->|"Parallel path"| F
+    F -->|"Step 5"| G
+    E -->|"Step 5 (alt)"| G
+```
+
+**Attack Chain Summary:**
+- Path 1 (Unauthenticated): F-001 directly → full DB exfiltration. No login required.
+- Path 2 (Authenticated): Credential stuffing (F-007) → session → SSRF (F-003) → AWS metadata → privilege escalation.
+- Both paths converge at customer data exfiltration.
+- Combined CVSS (chained): 9.9 (Critical)
+```
+
+---
+
+## MITRE ATT&CK Coverage Matrix Template
+
+```markdown
+## MITRE ATT&CK Coverage
+
+| Tactic              | Technique                                  | ID        | Findings      |
+|---------------------|-------------------------------------------|-----------|---------------|
+| Reconnaissance      | Active Scanning: Vulnerability Scanning   | T1595.002 | —             |
+| Initial Access      | Exploit Public-Facing Application         | T1190     | F-001, F-003  |
+| Initial Access      | Phishing: Spearphishing via Service       | T1566.003 | —             |
+| Credential Access   | Brute Force: Password Spraying            | T1110.003 | F-007         |
+| Defense Evasion     | Exploitation for Defense Evasion          | T1211     | F-002         |
+| Collection          | Data from Information Repositories       | T1213     | F-001, F-004  |
+| Lateral Movement    | Exploitation of Remote Services           | T1210     | F-003         |
+| Exfiltration        | Exfiltration Over Web Service             | T1567     | F-001, F-004  |
+
+**Tactics Coverage:** Initial Access, Credential Access, Collection, Exfiltration
+**Notable Gap:** No persistence mechanisms were tested (out of scope for this engagement).
+```
+
+---
+
+## Remediation Roadmap Template
+
+```markdown
+## Remediation Roadmap
+
+Remediations are ordered by risk priority (CVSS descending). Time estimates assume a team of 2 developers with security experience.
+
+### Track 1 — Immediate (0–7 days)
+
+| Priority | Finding | Action                                              | Effort | Owner        |
+|----------|---------|-----------------------------------------------------|--------|--------------|
+| 1        | F-001   | Deploy WAF rule for SQL metacharacters              | 2h     | DevOps       |
+| 2        | F-001   | Revoke DB user superuser/COPY privileges            | 1h     | DBA          |
+| 3        | F-002   | Force `alg: RS256` in JWT library config; reject `none` and `HS256` | 1h | Backend Dev |
+| 4        | F-003   | Block outbound HTTP from app servers to 169.254.x.x (IMDS) | 2h | DevOps |
+| 5        | F-004   | Add server-side authorization check on all `/account/{id}` endpoints | 4h | Backend Dev |
+
+### Track 2 — Short-term (8–30 days)
+
+| Priority | Finding | Action                                              | Effort | Owner        |
+|----------|---------|-----------------------------------------------------|--------|--------------|
+| 6        | F-001   | Refactor all raw SQL queries to parameterized queries | 3 days | Backend Dev |
+| 7        | F-005   | Implement output encoding on all user-generated content | 2 days | Frontend Dev |
+| 8        | F-007   | Implement rate limiting: 5 attempts / 15 min / IP  | 4h     | Backend Dev  |
+| 9        | F-006   | Disable verbose error responses in production; log internally only | 2h | Backend Dev |
+
+### Track 3 — Long-term (31–90 days)
+
+| Priority | Finding | Action                                              | Effort | Owner        |
+|----------|---------|-----------------------------------------------------|--------|--------------|
+| 10       | F-001   | Adopt ORM for all database access                   | 2 weeks | Backend Dev |
+| 11       | All     | Integrate DAST (OWASP ZAP) into CI/CD pipeline     | 3 days | DevOps       |
+| 12       | All     | Developer security training — OWASP Top 10 focus   | 1 day  | All Devs     |
+| 13       | F-008   | Enforce `Secure; HttpOnly; SameSite=Strict` on all cookies | 2h | Backend Dev |
+```
+
+---
+
+## Integration with finding_tracker.py and autodoc_engine.py
+
+### Pulling Finding Data for the Report
+
+```bash
+# Get formatted findings table for insertion into report
+python3 {project-root}/_rtexit/scripts/finding_tracker.py export --format md
+
+# Get JSON for programmatic processing
+python3 {project-root}/_rtexit/scripts/finding_tracker.py export --format json
+
+# Check that no findings are in UNCONFIRMED status before final report
+python3 {project-root}/_rtexit/scripts/finding_tracker.py list --status UNCONFIRMED
+# Should return: "No findings found."
+
+# Read individual finding MD files for full content
+# Files are at: {project-root}/_rtexit-output/docs/findings/F-NNN.md
+```
+
+### Logging Report Generation Activity
+
+```bash
+# Log that reporting phase started
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-technical-report \
+  --phase reporting \
+  --note "Technical report generation started"
+
+# Log that draft is complete
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-technical-report \
+  --phase reporting \
+  --note "Technical report draft complete — 8 findings documented"
+
+# Log final delivery
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py log \
+  --skill rt-technical-report \
+  --phase reporting \
+  --note "Technical report v1.0 delivered to client"
+```
+
+### Adding Evidence to Chain of Custody Before Report
+
+For every screenshot or terminal log referenced in the report, ensure it is logged:
+
+```bash
+python3 {project-root}/_rtexit/scripts/autodoc_engine.py custody \
+  --finding F-001 \
+  --evidence "_rtexit-output/docs/evidence/screenshots/F-001-sqli-version-dump.png" \
+  --operator "Ahmed Al-Rashidi"
+```
+
+### Output Path
+
+Save the finished report to:
+```
+{project-root}/_rtexit-output/docs/reports/technical-report-{engagement.ref}.md
+```
+
+Example:
+```
+_rtexit-output/docs/reports/technical-report-MFS-RT-WEB-2026-003.md
+```
+
+---
+
+## Compliance Mapping (Appendix C)
+
+```markdown
+## Appendix C — Compliance Mapping
+
+### PCI-DSS v4.0
+
+| Requirement                              | Control                              | Findings Violated |
+|------------------------------------------|--------------------------------------|-------------------|
+| 6.3.1 — Security vulnerabilities identified | Vulnerability management process | F-001, F-003      |
+| 6.4.1 — Public-facing web app protection  | WAF or code review                  | F-001, F-005      |
+| 8.3.1 — Authentication factors            | MFA / strong auth                   | F-002             |
+| 10.2.1 — Audit logs                       | Log all access to CHD               | F-006             |
+
+### GDPR (Regulation EU 2016/679)
+
+| Article | Requirement                             | Findings Violated |
+|---------|-----------------------------------------|-------------------|
+| Art. 5  | Integrity and confidentiality           | F-001, F-004      |
+| Art. 25 | Data protection by design and default   | F-001, F-007      |
+| Art. 32 | Security of processing                  | F-001, F-002, F-003|
+| Art. 83 | Administrative fines (up to 4% turnover)| All critical/high  |
+
+### ISO/IEC 27001:2022
+
+| Control | Domain                                  | Findings Violated |
+|---------|-----------------------------------------|-------------------|
+| A.8.24  | Use of cryptography                     | F-002             |
+| A.8.28  | Secure coding                           | F-001, F-005      |
+| A.8.8   | Management of technical vulnerabilities | F-001, F-003, F-004|
+| A.9.4.1 | Information access restriction          | F-004             |
+```
+
+---
+
+## Quality Checklist — Good Findings and Reports
+
+### Per-Finding Quality Gates
+
+A finding is report-ready when all of these are true:
+
+- [ ] **Reproducible:** Reproduction steps can be followed by a junior engineer with no prior context and produce the same result
+- [ ] **Evidence-backed:** At least one evidence block (HTTP response, command output, or screenshot) is included and referenced
+- [ ] **CVSS is justified:** The score matches the vector string. If AV is Network, the finding must actually be exploitable remotely.
+- [ ] **Business impact is specific:** Not "attacker could access data" — instead "attacker can read all 47,000 customer records including account numbers and password hashes"
+- [ ] **Remediation is actionable:** Each remediation item names a specific fix, not "fix the vulnerability". Includes code examples where relevant.
+- [ ] **MITRE mapped:** At least one tactic + technique pair is listed
+- [ ] **No placeholders remain:** No `[INSERT]`, `[TBD]`, or `TODO` text anywhere in the finding
+
+### Report-Level Quality Gates
+
+- [ ] All sections are present and filled — no empty sections
+- [ ] Finding IDs in the summary table match the IDs in the detailed sections
+- [ ] CVSS scores in the summary table match the scores in the finding sections
+- [ ] Attack chain diagrams cover all multi-step exploitation paths
+- [ ] MITRE coverage table is complete and consistent with per-finding mappings
+- [ ] Remediation roadmap covers every finding (including LOW and INFO)
+- [ ] Compliance mapping covers the frameworks specified in `_rtexit/config.toml` (pci_dss, gdpr, iso27001 by default)
+- [ ] Evidence files referenced in the report actually exist in `_rtexit-output/docs/evidence/`
+- [ ] No real credentials, production data, or PII appears in the report body (use redacted forms: `passw***`, `acc-XXXX`)
+- [ ] Chain of custody log is complete for all CRITICAL and HIGH evidence
+- [ ] Report is version-controlled in Document Control table
+
+---
+
+## Example Output — Finished Report Header
+
+The following shows what the first 50 lines of a finished, delivery-ready report look like. This is the standard to aim for.
+
+```markdown
+---
+CONFIDENTIAL — RESTRICTED DISTRIBUTION
+---
+
+# Penetration Testing Technical Report
+## Meridian Financial Services Ltd.
+
+**Engagement Reference:** MFS-RT-WEB-2026-003
+**Report Version:** 1.0 — Final
+**Report Date:** 2026-05-31
+**Classification:** Confidential
+**Prepared By:** Ahmed Al-Rashidi, Red Team Operations, elunic
+
+---
+
+## Document Control
+
+| Version | Date       | Author          | Changes                         |
+|---------|------------|-----------------|---------------------------------|
+| 0.1     | 2026-05-20 | Ahmed Al-Rashidi | Initial draft                  |
+| 1.0     | 2026-05-31 | Ahmed Al-Rashidi | Final — approved for delivery  |
+
+---
+
+## Executive Summary (Engineering Brief)
+
+The assessment of `portal.meridian-fs.com` and `api.meridian-fs.com` identified **8 vulnerabilities**, including **2 Critical** and **3 High** severity findings. The most severe finding (F-001, CVSS 9.8) allows an unauthenticated attacker to dump the complete customer database via SQL injection with no credentials required. A second Critical finding (F-002, CVSS 9.1) allows authentication bypass for any account via JWT algorithm confusion. Together these two findings represent an unacceptable risk to production systems and require immediate remediation before the next release.
+
+The full attack surface covered: authentication, session management, API authorization, input validation, SSRF, and client-side injection. Mobile and infrastructure were not in scope.
+
+**Recommended immediate actions:**
+1. Take `/v2/customers/search` offline or behind IP allowlist until F-001 is patched.
+2. Patch JWT library to reject `alg: none` and `alg: HS256` within 24 hours (F-002).
+3. Brief engineering team on this report within 48 hours.
+
+---
+
+## Findings Summary
+
+| ID    | Severity    | CVSS | Title                                          |
+|-------|------------|------|------------------------------------------------|
+| F-001 | 🔴 CRITICAL  | 9.8  | SQL Injection in Customer Search API           |
+| F-002 | 🔴 CRITICAL  | 9.1  | Authentication Bypass via JWT Algorithm Confusion |
+| F-003 | 🟠 HIGH     | 8.6  | SSRF in Document Export Function               |
+...
+```
+
+---
+
+## Common Mistakes to Avoid
+
+### Mistakes That Kill Report Quality
+
+**1. Writing vague impact statements**
+- Bad: "An attacker could access sensitive information."
+- Good: "An unauthenticated attacker can extract all rows from the `customers` table, including full name, national ID number, account balance, and bcrypt-hashed password for all 47,000 registered customers."
+
+**2. Reproduction steps that skip prerequisites**
+- Bad: "Send a malicious request to the endpoint."
+- Good: Include the full HTTP request, headers, parameter encoding, and the exact response that confirms exploitation.
+
+**3. Assigning CVSS scores that do not match the vector**
+- If you score AV:N (Network) but the vulnerability requires local access, the score is wrong. Verify each component of the vector string matches the actual conditions of exploitation.
+
+**4. Referencing evidence that does not exist**
+- Every screenshot path and terminal log reference must be to a file that is present in `_rtexit-output/docs/evidence/`. Verify before finalizing.
+
+**5. Writing remediations that are not actionable**
+- Bad: "Implement proper input validation."
+- Good: "Replace raw SQL concatenation with parameterized queries using the `psycopg2` library. Example: `cursor.execute('SELECT * FROM customers WHERE name = %s', (user_input,))`."
+
+**6. Missing the MITRE mapping**
+- Every finding must have at least one MITRE ATT&CK technique. If you cannot find a match, use T1190 (Exploit Public-Facing Application) as a baseline for web vulnerabilities, but look for a more specific technique first.
+
+**7. Including unredacted sensitive data**
+- Do not paste real customer names, real passwords, or real account numbers into the report body. Use redacted forms or describe what the data type was (e.g., "first row returned: email ending in @meridian-fs.com, 8-digit account number, bcrypt hash beginning with `$2b$12$`").
+
+**8. Running this skill before all findings are confirmed**
+- Running the report before all F-NNN.md files are complete produces a skeleton report. Always run `finding_tracker.py list --status UNCONFIRMED` first and resolve any unconfirmed findings.
+
+**9. Forgetting the attack chain section for multi-step exploits**
+- If two or more findings can be chained (SSRF + metadata service + privilege escalation), you must draw the chain. Single-finding thinking underestimates the real risk.
+
+**10. No version in Document Control**
+- Every report delivered to a client must have a version number and date. Draft versions are 0.x. Final delivery is 1.0. Revisions after client feedback are 1.1, 1.2, etc.