security-reviewlisted

# Security Review Threat-oriented review, language-agnostic, and the security entry point for the suite. The question is not "is this code good?" but "what can an untrusted actor make this code do?" For general correctness and maintainability, use `code-review`. Run both before shipping something that matters; they find different defects. ## Procedure Follow `../../references/procedure.md` for scoping, probing and error handling. Specifically: 1. **Establish the trust boundary first.** Before reading for defects, identify what is attacker-controlled: request parameters, headers, cookies, uploads, webhook payloads, queue messages, filenames, environment on shared hosts, and any data that made a round trip through storage. Everything downstream of an untrusted input is in scope; everything else is context. 2. **Scope.** The diff for a change review, the tree for an audit. State which you used: a clean result on three files is not a clean result on the application. 3. **Probe and run** the tools below. 4. **Enrich the CVEs.** Collect CVE IDs from scanner output with `grep -oE 'CVE-[0-9]{4}-[0-9]{4,}'` and pipe them through `../../nvd-enrich.sh`. Grepping the text rather than parsing a scanner's JSON keeps this working across output-format changes and across any scanner added later; the script deduplicates its own input. A CVE that comes back `unavailable` is still reported as a finding, with the enrichment gap named in `## Checks skipped`. Eac