Initial commit

2026-05-25 05:47:28 +00:00
commit 4d6495ffda
97 changed files with 13403 additions and 0 deletions
@@ -0,0 +1,121 @@
+---
+name: tdfddd-security-verification
+description: "Reviews TDFDDD design artifacts or implemented code for security risks. Use when manually asked to review requirements, domain models, workflow designs, ADRs, or changed code for trust boundaries, least privilege, zero trust, blast radius, and related security concerns."
+---
+
+# TDFDDD Security Verification
+
+Reviews design artifacts or implemented code for security risks.
+
+## When to Use This Skill
+
+Activate only when manually requested for a security review.
+
+This skill handles both **Design** and **Implementation** reviews depending on what the user asks you to look at.
+
+Do **not** implement fixes. This skill is **review-only**.
+
+## Security Philosophy
+
+The mechanical checks in this skill serve to enforce the following guiding principles:
+
+- **Assume Breach**: Understand that perimeters fail; assume malicious input and compromised components already exist inside the system.
+- **Zero Trust**: Never grant implicit trust based on network location or component origin. Verify identity, context, and input explicitly at every bounded seam.
+- **Least Privilege**: Ensure components, workflows, and services only possess the exact authority (capabilities, data access) required for the current slice, and nothing more.
+- **Defense in Depth**: Require multiple layers of security controls so that if one fails, others mitigate the impact.
+- **Blast Radius Reduction**: Ensure isolation boundaries prevent a compromise in one workflow or dependency from spreading across the rest of the system.
+
+## Core Rules
+
+1. **Grill the human first**: If scope is ambiguous, ask what to review before starting.
+2. **Review Target**: Default to reviewing the listed artifacts or the changed files plus adjacent seams. Check dependencies/versions *only* if the user requests "Expanded Surface Mode."
+3. **Findings Only**: Do not pad the report with positive confirmations.
+4. **Cite Evidence**: Every concrete finding must cite the exact file/line/section it comes from.
+5. **Categorize Risk**: 
+   - If you suspect a problem but cannot prove it, label it **Possible Concern**.
+   - If you cannot assess a category from the provided materials, label it **Insufficient Evidence**.
+6. Reference relevant external standards when useful, especially OWASP ASVS and OWASP cheat sheets.
+
+## Master Review Categories
+
+Review every category below. If a category is not visible in the provided scope, mark it accordingly rather than skipping it.
+
+1. Trust Boundaries & Data Flow
+2. Input Parsing & Validation (See `docs/explanation/architecture/input-security.md` for specific tainted string wrappers)
+3. Sink Handling & Contextual Sanitization
+4. Capabilities & Least Privilege
+5. Secrets & Sensitive Config
+6. Isolation & Blast Radius
+7. Dependency & Supply Chain Assumptions
+8. AuthN/AuthZ if applicable
+9. Logging, Telemetry & Detection
+10. Recovery & Failure Modes
+11. Unsafe Dynamic Behavior
+12. Security Testing Coverage
+
+## Phase-Specific Heuristics
+
+### If reviewing DESIGN artifacts:
+- Do not demand code-level proof from design artifacts.
+- Do demand that risky areas are named and bounded.
+- Missing security design information is itself a valid finding.
+- Treat “we will sanitize later” as weak unless the sink categories and ownership are explicit.
+- Prefer structural security reasoning:
+  - where untrusted data enters
+  - how it is parsed into trusted types
+  - what authority the workflow slice requires
+
+### If reviewing IMPLEMENTATION:
+- Look for raw untrusted data crossing into trusted domain types without parsing.
+- Look for sink misuse: SQL building, shell execution, HTML rendering, URLs, file paths, template rendering, logging, dynamic code loading.
+- Prefer parameterized APIs and framework safe sinks over handwritten escaping.
+- Look for over-broad injected capabilities, especially services that grant more authority than the workflow needs.
+- Distinguish purity from privilege: pure code can still orchestrate overly powerful services.
+- Treat missing tests at risky seams as a security finding.
+
+## Required Output Format
+
+```markdown
+# Security Verification Report
+
+## Phase: [Design / Implementation]
+
+## Scope Reviewed
+
+- ...
+
+## Artifacts Read
+
+- ...
+
+## Security Assumptions
+
+- ...
+
+## Overall Risk Summary
+
+- ...
+
+## 1. Trust Boundaries & Data Flow
+
+- [Finding|Possible Concern|Insufficient Evidence] Severity: X/10
+  - Evidence: file/section/line
+  - Why it matters: ...
+  - Suggested fix: ...
+
+## 2. Input Parsing & Validation
+
+...
+
+## 3. Sink Handling & Contextual Sanitization
+
+... (continue for all 12 categories) ...
+
+## Cross-Cutting Questions
+
+- ...
+
+## Suggested Next Actions
+
+- ...
+```