playbook/codex/skills/defense-in-depth/SKILL.md

name	description
defense-in-depth	Defense in depth: add layered validation/guardrails across a data path (auth, validation, invariants, rate limits, idempotency). Triggers: defense in depth, guardrails, harden, 分层校验, 多道防线, 安全加固.

Defense in Depth（分层校验 / 多道防线）

When to Use

• Auth/data path changes (permissions, roles, ownership checks)
• Risky inputs (user input, external APIs, files, SQL, commands)
• Operations that must be safe under retries/concurrency
• Incidents where we fixed symptoms but not the root class of bugs

Inputs（required）

• Data path: entrypoints → core logic → side effects (DB/files/network)
• Threat model: what could go wrong? who can trigger it?
• Constraints: latency budgets, backward compatibility, rollout plan
• Verification: how to prove guardrails work (tests, logs, metrics)

Procedure（default）

1. Map the Path

   • Identify trust boundaries and validation points
   • List invariants that must always hold

2. Layer Guardrails

   • AuthN/AuthZ checks at boundaries (least privilege)
   • Input validation + normalization (reject early)
   • Business invariants (defensive checks with clear errors)
   • Idempotency / dedup / retry-safety
   • Rate limits / resource bounds (timeouts, size limits)
   • Observability (structured logs, metrics, alerts)

3. Failure Modes

   • Define what happens on invalid input, partial failures, timeouts
   • Ensure errors are actionable and do not leak sensitive info

4. Verify

   • Add tests for each guardrail and key edge cases
   • Propose minimal manual verification steps if tests are missing

Output Contract（stable）

• Path map: trust boundaries + invariants
• Guardrails: what to add at each layer (with rationale)
• Risks: what remains and why
• Verification: exact tests/commands and expected signals

Guardrails

• Avoid “one big check”; prefer multiple small, well-scoped checks
• Prefer explicit errors over silent fallback
• Security checks must not be bypassable via alternate code paths