security-review

Review-only: findings go to the author; this pass does not edit code.

Before you start

• Read docs/threat-model.md: its trust boundaries and controls are the baseline you check against.
• Read the change: the diff against the target branch, including tests, docs, config, and lockfile changes; or, for a plan, the change proposal.
• Note the exposure from docs/context.md → Lifecycle: who can reach this today, and with what data.

Walk the boundary

For each entry point the change adds or alters, trace user-controlled input to every sink it reaches, across files. Check removed or weakened controls as carefully as new code.

Before reporting a finding, confirm the path is reachable and that no framework or upstream control already blocks it.

Severity

Rate each finding against current exposure, not worst case:

• High: exploitable by someone who can reach the system today. Blocks merge.
• Medium: exploitable under a plausible near-term condition. Fix or defer with an owner.
• Low / hardening: needs traffic, data, or consumers that do not exist yet. Record it in the production register with its trigger; do not expand the diff for it.

Report

Return the report to the author, who puts it in the PR, or in the proposal for a plan. Check that the change updates the trust-boundary table in docs/threat-model.md for the boundary it moves.

**Security review** of {PR, branch, or proposal} at {commit}

- **Reviewed:** {boundaries and files covered}; **not reviewed:** {and why, or "nothing"}

| # | Finding | Severity | Resolution |
| --- | --- | --- | --- |
| 1 | {what and where} | High | Fixed in {commit} |

- **Deferred to register:** {items, or none}
- **Limits:** {what this review could not see, e.g. deployed configuration}

An open High finding blocks merge. Required content you could not read is a gap: say so in the report and block rather than reporting clean.