gh-export

GitHub Issue Export

Purpose

Read findings.json from the current pentest session and produce one copy-pasteable GitHub issue markdown block per confirmed finding.

Each block follows the AppSec reporting guide format — concrete impact, reproducible steps, raw PoC — so developers can act immediately without back-and-forth.

Workflow

1. Read findings.json from the repo root (or the path provided in $ARGUMENTS if given)
2. For each entry in findings[].findings (skip diagram entries):
   • Format it using the template below
   • Check pocs/ for any .http file whose name contains a keyword from the finding title — if found, read it and paste the content into the PoC block
   • After formatting the block, call http(action="request", ...) with method PATCH, url http://localhost:7777/api/findings/{finding.id}, body {"gh_issue": "<the formatted markdown block>"}, and headers {"Content-Type": "application/json"} — this couples the block to the finding in the dashboard
3. Write all formatted blocks to gh-issues.md in the repo root, separated by ---, with a header line # GitHub Issues — <target> — <date> at the top. Create or overwrite the file.
4. Print all blocks consecutively with a --- separator between them
5. After the last block, print a one-line summary: X issue(s) ready to file — saved to gh-issues.md and copied above.

Output Template

For every finding, output exactly this structure (omit ## Browsers Verified In for non-browser/non-web findings):

**Summary:** <one sentence: what the vulnerability is and which component/endpoint is affected>

**Impact:** <what an attacker can concretely do — name the data exposed, the privilege gained, or the service disrupted. Never write "could lead to" — write "allows an attacker to". One short paragraph.>

**Severity Level:** <Critical | High | Medium | Low>

## Steps To Reproduce:

1. <exact first step — full URL, parameter name, payload>
2. <exact second step>
3. <what to observe in the response that confirms the issue>