secure-code-reviewlisted

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/secure-code-review/SKILL.md. --> # Secure Code Review The sinks and boundaries that belong to no framework: passing input to a shell or an evaluator, letting input choose a filesystem path, validating at a boundary that is not an HTTP request, and handling regulated data (PII, PHI, cardholder data) so it does not spread into paths nobody reviews. Use when generating or reviewing code that shells out, touches the filesystem, reads a queue message, CLI argument, or parsed file, or when a change crosses a PII, PHI, or PCI boundary. ## ALWAYS - Validate input at **every** trust boundary, not only the HTTP one. A CLI argument, an environment variable, a queue message, a filename, a parsed config or spreadsheet cell all arrive from outside and none of them pass through the request-validation layer. Check type, length, allowed characters and allowed range, and reject before processing. `api-security` owns the HTTP request body and its schema; this rule is every other way input gets in. - Build a command as an **argument vector**, never as a string a shell will parse: `subprocess.run([...])` without `shell=True`, `execFile`/`spawn` with an array, `exec.Command(name, args...)`. Passing an array is what removes the shell, and removing the shell is what removes the injection — quoting and escaping are the fallback f