The contained runner that drove the 2026-09 security audit, the README review and four rounds of design ideation lived only inside the ignored notebook. It moves to scripts/agent-runner/: the prepare, tools, audit, ideation and teardown scripts, the compose and container files, the allowlist proxy and the prompt templates, with the paths that assumed the notebook fixed and findings written to a caller-named directory. Run outputs, transcripts and the round-specific sheet scripts stay behind. docs/agent-runner.md states the method: the disposable git archive copy and the fail-closed proxy, how a task is shaped, union rather than intersection of findings across models, separate adjudication of every finding against the source, and the evidence a finding must carry.
3.9 KiB
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
- Read the whole slice. The files named in your task, plus what they call and what calls them. Do not skim; do not sample.
- Answer the task's questions. They are falsifiable. Each must end up with a yes or a no and the code that settles it.
- 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.
- 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 -vPre-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-rangeand 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 undertest/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.