Evidence & Reporting

Capture proof as you go, structure findings consistently, and turn a pile of scan output into a deliverable.

The report is the product. A client doesn’t pay for scans — they pay for a clear, reproducible account of what’s wrong and how to fix it. The single biggest quality multiplier is capturing evidence as you find it, not reconstructing it the night before the deadline.

Capture evidence in the moment

When you confirm something, grab proof immediately — the request/response, a screenshot, the exact command. You won’t be able to recreate a transient condition later.

Screenshots of the rendered finding (login bypassed, data exposed, admin console reached). Arsenic’s screenshot helper drops a timestamped PNG into report/static/ and copies a Markdown image tag to your clipboard, so you can paste it straight into notes. The mechanics:
```
ts=$(date +'%Y-%m-%d_%H%M')
flameshot gui -p "report/static/finding-name-$ts.png"   # or: maim -s, scrot -s
```
Raw request/response for web findings — save the full HTTP exchange (Burp “Copy to file”, or curl -v). This is what makes a finding reproducible.
The exact command you ran, with output. Your git-tracked scan files already hold most of this — another reason to commit as you go (see Engagement Setup).

Structure each finding consistently

Use one folder per finding with a fixed file layout, so every finding has the same sections (this is Arsenic’s report/findings/ convention):

report/findings/sql-injection-login/
├── 00-metadata.md          # title, severity, CVSS, affected assets, status
├── 01-summary.md           # what it is, in plain language
├── 02-affected-assets.md   # exact URLs / hosts / parameters
├── 03-recommendations.md   # how to fix it
├── 04-references.md        # CWE, CVE, vendor advisories, OWASP
└── 05-steps-to-reproduce.md # numbered steps + evidence screenshots

A good finding answers, in order: what is it? Where is it? How bad is it? How do I prove it? How do I fix it?

Rate severity defensibly

Use a consistent scale — CVSS 3.1 is the common denominator — but adjust for business context. A medium-severity exposure on an internet-facing admin panel with customer data outranks a “high” on a decommissioned staging box. State your reasoning so the rating holds up in the readout.

Assemble the deliverable

A typical report structure:

Executive summary — risk in business terms, for non-technical readers.
Methodology & scope — what you tested, what you didn’t, when, and how. Your phase-by-phase workflow is this section.
Findings — sorted by severity, each in the structure above.
Appendices — full host/service inventory, tool versions, raw output references.

Hugo / Docsy as a report engine

Because this whole workspace is Markdown in git, a static-site generator makes a natural reporting front end. arsenic-hugo renders the hosts/, recon/, and report/ trees into a browsable site — host inventory, screenshot galleries, and findings. It’s handy for collaborating with a team and for handing clients an interactive deliverable alongside the PDF.

Close out cleanly

Re-test any findings the client remediates and note the verification.
Archive the git repo and evidence per your data-retention agreement, then securely delete client data when the retention window closes.
Capture lessons learned — a new tool, a new wordlist, a step worth automating next time. That feedback loop is exactly how this toolchain (and Arsenic) grew in the first place.