Code change security review

Ingredients

• Pull request diff (unified or side-by-side)
• Threat model for the affected component
• Checklist: auth, input validation, secrets, logging, dependency changes
• One reviewer with security context

Steps

1. Scope the blast radius. Identify every endpoint, table, and external service touched by the diff.
2. Walk the auth boundary. Confirm every new code path enforces authentication and authorization. No anonymous fallthrough.
3. Audit inputs. Trace every user-supplied value — query params, body fields, headers, file uploads — and verify validation, sanitization, and length caps.
4. Check secrets hygiene. Scan for hardcoded keys, tokens, or connection strings. Ensure secrets are read from environment variables or a vault at runtime.
5. Review logging. Strip PII, session tokens, and passwords from log statements. Confirm sensitive data is redacted before it hits stdout or a collector.
6. Inspect dependencies. If package.json, requirements.txt, or go.mod changed, verify new packages are maintained, signed, and free of known CVEs.
7. Sign off. The security reviewer approves only after every item on the checklist is satisfied. No exceptions.