# Security audit — auditor instructions

You are auditing member-console, a Go + HTMX web application. `CONTEXT.md`
gives you the system's auth model, request pipeline, and trust boundaries;
read it first and treat it as fact. Your task file names the slice you are
responsible for and the questions it must answer.

Your working directory is a disposable copy. Read anything, run anything.

## How to work

1. **Read the whole slice.** The files named in your task, plus what they call
   and what calls them. Do not skim; do not sample.
2. **Answer the task's questions.** They are falsifiable. Each must end up with
   a yes or a no and the code that settles it.
3. **Then hunt freely inside the slice.** The questions are the floor, not the
   ceiling. Anything security-relevant you find in these files counts, whatever
   its category. Do not restrict yourself to a vulnerability taxonomy.
4. **Use the scanners.** They are installed and run offline:
   - `gosec -fmt=json -quiet ./...`
   - `govulncheck -db=file:///opt/vulndb -format=json ./...`
   - `semgrep --metrics=off --json --config /opt/semgrep-rules/go --config /opt/semgrep-rules/generic .`
   - `staticcheck ./...` · `gitleaks detect --no-git -v`
   Pre-computed output for the whole repo may already sit in `/out/tools/`.
   Scanner output is a lead, not a finding: confirm every hit in the source,
   and say so when a hit is a false positive.

## The evidence toll

A finding that does not pay it is deleted before you write your report.

- An exact `path:line-range` **and a verbatim quote** of the code. If you
  cannot quote it, you have not found it.
- The **full path from attacker-controlled input to the dangerous operation**,
  naming each function it passes through. "Probably reachable" is not a path.
- The **preconditions**: what the attacker must already have (no session, a
  member session, an operator session, a Stripe signing key, DNS control).
- A **failure scenario**: concrete inputs and state, and the wrong outcome.

## What not to do

- Do not fix code, write patches, or suggest refactors.
- Do not invent CVE or CWE identifiers. If you cannot name one from memory
  with confidence, describe the bug class in words instead.
- Do not report missing hardening as a vulnerability. It goes under
  Miscellaneous (below).
- Do not report the `TEST-ONLY-*` fixtures under `test/` as leaked secrets.
- Do not re-check your own findings by arguing with yourself. A separate
  reviewer does that. Self-critique loops make security reports worse.

## Rating: two independent axes

**Severity** — Informational, Low, Medium, High, Critical.
**Difficulty** — how hard the attack is:
- *Low*: public tools exist, or it can be scripted.
- *Medium*: the attacker must write an exploit.
- *High*: the attacker needs privileged access, or must first find another bug.

Rate both. Do not produce a CVSS score. Do not report a confidence percentage.

## Output

Write to standard output, in this shape:

```
# <task id> — <task title> — <model>

## Coverage
Files actually read, and anything in the slice you did NOT get to. Be honest;
an unreviewed file named here is more useful than a silent gap.

## Answers to the task questions
One numbered answer per question: Yes / No / Undetermined, then the code that
settles it (path:line + quote). "Undetermined" is a legitimate answer.

## Vulnerabilities
### [Severity/Difficulty] <one-line title>
- **Where:** path:line-range
- **Code:** <verbatim quote>
- **Path:** <input -> ... -> dangerous operation>
- **Preconditions:** <what the attacker needs>
- **Failure scenario:** <concrete>

## Miscellaneous
Hardening, defence-in-depth, and hygiene. Same citation rules, no severity.
These are deliberately kept out of the vulnerability count.

## Scanner triage
Any scanner hit in your slice: confirmed real, or false positive and why.
```

If a section is empty, write the heading and "None." Finding nothing is a
valid result and is more useful than a padded report.

End with `COMPLETE` on its own line.