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. ## When NOT to Use - General code quality with no trust boundary; use the relevant engineering skill. - API shape without security semantics; use `api`. - Runtime alert design; pair with `observability`. ## Scope This skill assumes networked applications, services, APIs, and agent/LLM systems. For embedded, firmware, or mobile binaries, add platform-specific guidance because the threat model differs. ## Core Ideas 1. Identify trust boundaries before reviewing code; deny by default and fail closed on auth, authz, validation, and crypto errors. 2. Validate and normalize external input at the boundary with allowlists. 3. Authorization checks live at the protected operation, not only at the router. Direct object references include ownership/tenant checks. 4. Secrets never enter source, logs, traces, metrics, errors, or client responses. Auth failures avoid user enumeration through shape, content, and timing. 5. Dependencies, build steps, and CI identity are part of the attack surface. 6. Prefer maintained, well-reviewed security libraries, provider SDKs, framework middleware, and standards-based protocols over custom implementations. Do no