logging-securitylisted

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/logging-security/SKILL.md. --> # Logging Security Keep secrets and personal data out of logs at the call site rather than relying on redaction, neutralize log and field injection, record audit events that survive, and treat log read access as data access. Use when generating logger calls or structured-logging schemas, wiring log shippers, sinks, retention, and access controls, or specifying audit-logging requirements. ## ALWAYS - Decide what is safe to log **at the call site**, and log a reference rather than a value: an id, a hash, a type, a count. A redactor is the last net, not the design — it matches field names and known patterns, so it cannot see personal data sitting inside an assembled string. A formatted notification body, a templated message, an exception with interpolated arguments: the name and the address are in the prose, in no named field, matching no pattern. Nothing downstream will catch that. - Run a **redactor** at the sink anyway, for the cases the call site missed: credential-shaped values, `Authorization` and `Cookie` headers, query strings carrying tokens, and the personal-data patterns in `rules/redaction_patterns.json`. `secret-detection` owns which literals count as a credential; this rule is that the redactor exists and runs before anything leaves the process. - Log in a **structured format** (JSON or l