Merge commit 'ac794a6a7051497ff60b947642d44f0f8c04d6c6' into lsp-server
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: defense-in-depth
|
||||
description:
|
||||
"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
|
||||
Reference in New Issue
Block a user