Remediate six confirmed security issues: deployment-only config keys, bounded provider responses, short-lived registration sessions, private init file mode, FedWiki workflow authorization, and switch preview gates. - Add DeploymentOnly config key declaration; refuse runtime overrides for keys that decide where secrets are sent - Create httplimit package; bound all provider response reads at 8 MiB - Set fifteen-minute deadline on /register sessions - Write mc-config.yaml with 0600 permissions - Derive FedWiki workflow IDs from site IDs; re-authorize sites before mutating activities - Apply switch authorization gates to the proration preview
72 lines
2.6 KiB
Markdown
72 lines
2.6 KiB
Markdown
# What a finding must carry, and the shape of the report
|
|
|
|
## 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 you did NOT get to. Be honest; an
|
|
unreviewed file named here is more useful than a silent gap.
|
|
|
|
## Answers to the task questions
|
|
Only when the task asked 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 what you read: 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.
|