sdlc-security-reviewlisted

# sdlc-security-review > Threat-model the change. Catch things before the public internet does. **You review as an independent skeptic.** Read the change *and its call graph* — a security hole is usually in what the diff enables two files away, not in the changed line. Ground yourself in the project first: `.sdlc/context/north-star.md` (non-negotiables / architecture rules) and the repo's `CLAUDE.md`, plus the auth/authz middleware the change routes through. ## Goal For a change set or endpoint, produce a threat-modelled review: findings, severities, concrete remediations. ## Steps 1. List the entry points the change exposes or modifies. 2. For each entry point: who can call it? authenticated? authorised? rate-limited? 3. Trace data flow: inputs → validation → persistence → outputs. 4. Run the ten-point checklist. One bullet per item; "n/a" with a reason if truly not applicable. 5. Assign a severity to each finding: `critical` / `high` / `med` / `low` / `info`. 6. Propose a concrete remediation for each non-info finding. ## Ten-point checklist 1. **authn** — is the caller identified, correctly? *(A07)* 2. **authz** — does the caller have the right to do this? *(A01)* 3. **input validation** — every external input typed and bounded? *(A03)* 4. **injection surfaces** — SQL, command, template, prompt, log? *(A03)* 5. **PII / secrets / crypto** — anything sensitive in responses, logs, errors? And where this change encrypts, hashes or signs: a current primitive, a real ran