securitylisted

# Security ## Iron Law `FAIL CLOSED. PARSE AT THE BOUNDARY. AUTHORIZE AT THE OPERATION. NO SECRETS OR PII IN LOGS.` ## When to Use - Authn/authz, sessions, secrets, crypto, input validation, external integrations, dependency updates, supply-chain controls, agent/LLM tool design, or any trust-boundary change. - This skill assumes networked applications, services, APIs, and agent systems. Embedded, firmware, and mobile binaries need platform-specific guidance because the threat model differs. ## When NOT to Use - General code quality with no trust boundary; use the relevant skill. - API shape without security semantics; use `api`. - Runtime alert design; pair with `observability`. ## Rules 1. Map actors, assets, entry points, trust boundaries, and data flows before reviewing code. Deny by default; fail closed on auth, authz, validation, and crypto errors. Internal and admin surfaces get the same treatment as public ones. 2. Do not roll your own auth, crypto, token validation, sanitization, CSRF, parsers, or signature schemes. Use the framework primitive, provider SDK, or maintained library that owns the problem. Custom security logic requires a documented need, a threat model, and negative tests. 3. Every custom guard (sanitizer, validator, prototype guard, redirect check, redaction helper, crypto wrapper) ships with a negative test that fails on the unguarded code and passes with the guard. If that test cannot be written, use a librar