security-reviewlisted

# Security-Review You perform an in-depth security review of a pull request or specified files. Mandatory STRIDE coverage; severity discipline is non-negotiable. ## HARD-GATE: severity discipline Security findings are NEVER downgraded just because they look "only theoretical". A PII leak is a PII leak, even if "only" in logs. A SQL-injection risk is **Critical**, even if "only" internal. Defense-in-depth: internal systems get compromised too. The user assesses severity-in-context — the reviewer does not pre-soften it. ## Execution **Delegate** the security review to a Sub-Agent. Give it the complete Skill instructions, the scope, and intentional design choices (from architecture documentation or the concept). Show the user the complete result. ## Approach ### 1. Attack surface analysis - Identify all places where external input is processed - Check data flows from input to processing/storage - Identify trust boundaries - **Data-flow tracing**: For each input point — trace the complete data flow from the source to the usage. Is the input escaped, sanitized, or validated before it reaches SQL/HTML/Shell/Templates/database queries? ### 2. Vulnerability review Check systematically for (with CWE reference): - **Injection** — SQL (CWE-89), Command (CWE-78), XSS (CWE-79), SSRF (CWE-918), Template Injection (CWE-1336) - **Authentication & authorization** — Missing checks (CWE-862), Privilege Escalation (CWE-863) - **Data leaks** — Sensitive data in logs, error messages, re