# 252 P6 Risk Validation 4e7c1437 > - Skill: `tools-only/252-p6-risk-validation-4e7c1437` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tools-only/252-p6-risk-validation-4e7c1437` - Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/252-p6-risk-validation-4e7c1437/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: tools-only (https://skillmd.com/u/tools-only) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tools-only/252-p6-risk-validation-4e7c1437 --- # Phase 6: Risk Validation **Type**: Verification **Executor**: LLM **Knowledge**: CAPEC → ATT&CK → CVE/KEV, WSTG, MASTG --- ## ⚠️ MANDATORY: 4-Phase Gating Protocol (BLOCKING) > **CRITICAL**: 必须按顺序完成以下四个阶段，并**输出每个阶段的结果**。跳过任何阶段将导致分析质量下降！ > **⚠️ CHECKPOINT PHASE**: P6是用户检查点，复杂分析完成后请求用户确认。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### 🧠 THINKING - Phase 6 Entry Gate ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Purpose**: 聚合所有P1-P5数据，设计攻击路径和POC验证威胁。 **⚠️ 你必须输出以下格式的 THINKING 结果：** ``` 🧠 THINKING - P6 Entry Gate ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📌 CORE PROBLEM 验证威胁可利用性，设计攻击路径和POC，NOT缓解措施 📊 UPSTREAM DATA (从 P1-P5 YAML 读取) | 指标 | 值 | 来源 | |------|-----|------| | P1模块数 | {实际值} | P1_project_context.yaml | | P1入口点数 | {实际值} | P1_project_context.yaml | | P2 DFD元素数 | {实际值} | P2_dfd_elements.yaml | | P3边界数 | {实际值} | P3_boundary_context.yaml | | P4 Gap数 | {实际值} | P4_security_gaps.yaml | | P5威胁总数 | {实际值} | P5_threat_inventory.yaml → summary.total ⬅ COUNT CONSERVATION基准 | ❓ UNKNOWNS - 威胁实际可利用性 - 攻击路径可行性 - POC执行前提条件 ⚠️ RISKS - Count Conservation失败: P5.total ≠ verified + theoretical + pending + excluded - Critical/High威胁缺少POC - 攻击链缺少ASCII图 - findings_coverage < 100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ⛔ STOP CHECK - P1-P5 全部YAML已读取? [YES/NO] - P5威胁总数已记录 (Count Conservation基准)? [YES/NO] - 上游数据完整? [YES/NO] - 可以继续PLANNING? [YES/NO] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ⛔ **STOP条件**: 如果任何 STOP CHECK = NO → 先读取上游数据再继续 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### 📋 PLANNING - Sub-task Decomposition ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Step 1: 读取ALL上游数据** (BLOCKING - 必须执行) ```bash # 聚合所有P1-P5数据 python scripts/phase_data.py --aggregate --phases 1,2,3,4,5 --format summary --root . # 验证P5威胁数 (Count Conservation基准) python scripts/phase_data.py --verify-p5-coverage --root . # 或直接读取全部 cat .phase_working/{SESSION_ID}/data/P1_project_context.yaml cat .phase_working/{SESSION_ID}/data/P2_dfd_elements.yaml cat .phase_working/{SESSION_ID}/data/P3_boundary_context.yaml cat .phase_working/{SESSION_ID}/data/P4_security_gaps.yaml cat .phase_working/{SESSION_ID}/data/P5_threat_inventory.yaml ``` ⛔ 如果任何上游YAML不存在或无效 → STOP并返回完成上游Phase **Step 2: 输出子任务表格** (MANDATORY) **⚠️ 你必须输出以下格式的 PLANNING 结果：** ``` 📋 PLANNING - P6 Sub-tasks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | # | 子任务 | 预期输出 | |---|--------|----------| | T1 | 聚合P1-P5所有发现 (F-P1-xxx, GAP-xxx, T-xxx) | 聚合清单 | | T2 | 聚类相关发现，创建VR-xxx | 风险清单 | | T3 | 验证威胁可利用性 | verified/theoretical/pending/excluded | | T4 | 设计Critical/High威胁的POC | POC-xxx详情 | | T5 | 设计攻击路径 (AP-xxx) 和攻击链 (AC-xxx) | 攻击链 + ASCII | | T6 | 验证Count Conservation公式 | conservation_verified = true | | T7 | 写入最终输出 | P6_validated_risks.yaml + MD | ⛔ PLANNING CHECK - 子任务已分解? [YES/NO] - 准备创建 TaskCreate? [YES/NO] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` **Step 3: TaskCreate for ALL sub-tasks** (MANDATORY) ⚠️ 在开始任何实施前，必须执行 `TaskCreate` 创建所有子任务！ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### ⚡ EXECUTION LOOP ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ For each sub-task: 1. `TaskUpdate(status: "in_progress")` 2. 实施子任务 3. 验证: 输出是否符合预期？ 4. If 验证通过: `TaskUpdate(status: "completed")` → 下一个 5. If 验证失败: 诊断 → 修复 → 重试 (max 3x) → 如仍失败: CHECKPOINT请求用户决策 **输出顺序** (CRITICAL): 1. **先写YAML**: `.phase_working/{SESSION_ID}/data/P6_validated_risks.yaml` 2. **后写MD**: `.phase_working/{SESSION_ID}/reports/P6-RISK-VALIDATION.md` **Count Conservation验证** (MANDATORY): ``` P5.threat_inventory.total = verified + theoretical + pending + excluded ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ### 🔍 REFLECTION - Completion Verification ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **⚠️ 完成 EXECUTION 后，你必须输出以下格式的 REFLECTION 结果：** ``` 🔍 REFLECTION - P6 Completion Check ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | 检查项 | 状态 | |--------|------| | ALL P1-P5 YAML数据已读取并理解? | [✅/❌] | | P6_validated_risks.yaml 存在且有效? | [✅/❌] | | count_conservation.conservation_verified == true? | [✅/❌] | | findings_coverage_verification 存在? | [✅/❌] | | p4_gaps.coverage_percentage == 100%? | [✅/❌] | | p5_threats.coverage_percentage == 100%? | [✅/❌] | | 所有excluded_findings有documented reasons? | [✅/❌] | | Critical/High VR-xxx有POC-xxx详情? | [✅/❌] | | attack_chains 存在且有ASCII图? | [✅/❌] | | Hook验证通过 (exit 0)? | [✅/❌] | ⛔ COMPLETION GATE - 所有检查通过? [YES/NO] - 可以进入P7? [YES/NO] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ⛔ 任何检查失败 → 修复并重新验证，直到全部通过 --- ## ⚠️ MANDATORY OUTPUT RULES > **CRITICAL**: Phase 6 requires TWO outputs - a YAML data file AND a Markdown report. ### Dual Output Requirement ``` ┌─────────────────────────────────────────────────────────────────────┐ │ PHASE 6 MUST PRODUCE TWO FILES: │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 1. DATA FILE (PRIMARY - Write First!) │ │ Path: .phase_working/{SESSION_ID}/data/P6_validated_risks.yaml │ │ Purpose: Structured validated risk data for P7 to read │ │ Format: Valid YAML with schema_version: "3.0.0 (20260201a)" │ │ │ │ 2. REPORT FILE (SECONDARY - Write After Data!) │ │ Path: .phase_working/{SESSION_ID}/reports/P6-RISK-VALIDATION.md │ │ Purpose: Human-readable risk validation with POCs │ │ Format: Markdown with attack chains and ASCII diagrams │ │ │ │ INPUT REQUIREMENT: │ │ Read: .phase_working/{SESSION_ID}/data/P5_threat_inventory.yaml │ │ Read: .phase_working/{SESSION_ID}/data/P4_security_gaps.yaml │ │ ❌ DO NOT read previous .md reports for data extraction │ │ ✅ REQUIRED: Parse YAML files for threat_inventory, gaps │ │ │ └─────────────────────────────────────────────────────────────────────┘ ``` ### Required Data Sections in YAML | Section | Validation | |---------|------------| | `risk_summary` | BLOCKING - counts must balance (count conservation) | | `risk_details[]` | BLOCKING - all validated risks with VR-xxx IDs | | `poc_details[]` | BLOCKING - POCs for Critical/High risks | | `attack_chains[]` | WARNING - attack chain documentation | ### Validation Gate Phase 6 CANNOT complete until: 1. `.phase_working/{SESSION_ID}/data/P6_validated_risks.yaml` exists and is valid YAML 2. Count conservation: P5.total == verified + theoretical + pending + excluded 3. Critical/High risks have POC details 4. `.phase_working/{SESSION_ID}/reports/P6-RISK-VALIDATION.md` exists --- ## Error Handling | Error | Cause | Recovery Action | |-------|-------|-----------------| | P5 YAML not found | P5 not completed | Return to P5, complete STRIDE analysis | | Missing previous phase data | Incomplete workflow | Document gap, proceed with available data | | Count conservation failure | Threat accounting error | Recount threats, verify all threat_refs | | POC execution blocked | Environment constraint | Mark as `pending`, document prerequisites | | SAST tool unavailable | Tool not installed | Skip tool evidence, document limitation | **Fallback Strategy**: If count conservation cannot be verified due to missing data, document the gap and set `conservation_verified: false` with note explaining the discrepancy. --- ## Input Context ← ALL P1-P5: Read from `.phase_working/{SESSION_ID}/data/P{1-5}_*.yaml` **CRITICAL**: Phase 6 consolidates ALL previous findings, not just Phase 5 threats. ### ⚠️ MANDATORY: Query P1-P5 Data Before Validation **Before starting P6 risk validation**, LLM MUST execute these queries to obtain ALL upstream data: ```bash # Step 1: Get aggregate summary from all phases python scripts/phase_data.py --aggregate --phases 1,2,3,4,5 --format summary --root . # Step 2: Get P5 threat inventory (PRIMARY input) python scripts/phase_data.py --query --phase 5 --type threats --root . # Step 3: Get P4 security gaps for consolidated view python scripts/phase_data.py --query --phase 4 --type gaps --root . # Step 4: Verify P5 count for conservation formula python scripts/phase_data.py --verify-p5-coverage --root . ``` **Or read YAML directly**: ```bash # PRIMARY sources - ALL REQUIRED for Count Conservation cat .phase_working/{SESSION_ID}/data/P1_project_context.yaml cat .phase_working/{SESSION_ID}/data/P2_dfd_elements.yaml cat .phase_working/{SESSION_ID}/data/P3_boundary_context.yaml cat .phase_working/{SESSION_ID}/data/P4_security_gaps.yaml cat .phase_working/{SESSION_ID}/data/P5_threat_inventory.yaml ``` **CRITICAL**: Count Conservation Formula MUST hold: ``` P5.threat_inventory.total = P6.verified + P6.theoretical + P6.pending + P6.excluded ``` Do NOT validate risks from memory. MUST read P5 threat data to verify counts! ### ⚠️ P6 Data Aggregation Contract (MANDATORY) **Phase 6 MUST aggregate data from ALL previous phases with explicit tracking**: ```yaml # Required section in P6_validated_risks.yaml input_aggregation: schema_version: "3.0.0 (20260201a)" aggregated_at: "2026-01-31T12:00:00Z" # Source file checksums for integrity verification source_files: P1_project_context: path: ".phase_working/{SESSION_ID}/data/P1_project_context.yaml" exists: true checksum_sha256: "abc123..." # Optional but recommended P2_dfd_elements: path: ".phase_working/{SESSION_ID}/data/P2_dfd_elements.yaml" exists: true P3_boundary_context: path: ".phase_working/{SESSION_ID}/data/P3_boundary_context.yaml" exists: true P4_security_gaps: path: ".phase_working/{SESSION_ID}/data/P4_security_gaps.yaml" exists: true P5_threat_inventory: path: ".phase_working/{SESSION_ID}/data/P5_threat_inventory.yaml" exists: true mandatory: true # P6 cannot proceed without P5 # Extracted counts from each phase (for verification) extracted_counts: p1_modules: 15 p1_entry_points: 23 p1_findings: 5 # F-P1-xxx count p2_dfd_elements: 45 # Total: EI + P + DS + DF p2_findings: 8 # F-P2-xxx count p3_boundaries: 6 p3_findings: 3 # F-P3-xxx count p4_security_gaps: 12 # GAP-xxx count p5_threats: 67 # T-xxx count (PRIMARY for conservation) # Count Conservation Verification count_conservation: p5_total_threats: 67 p6_verified: 15 # Confirmed exploitable p6_theoretical: 35 # Valid but not verified p6_pending: 10 # Awaiting verification p6_excluded: 7 # Not applicable with reason conservation_sum: 67 # MUST equal p5_total_threats conservation_verified: true verification_formula: "verified + theoretical + pending + excluded == p5_total" # If conservation fails, document discrepancy discrepancy_notes: null # Or explain if conservation_verified: false # All Finding Sources Tracking findings_consolidation: total_findings_input: 28 # Sum of all F-P*-xxx + GAP-xxx findings_mapped_to_vr: 25 # Findings that contributed to VR-xxx findings_not_mapped: 3 # Findings not linked to any VR unmapped_findings: # MUST document why each is unmapped - finding_id: F-P1-003 reason: "Informational only, no security impact" - finding_id: F-P2-007 reason: "Duplicate of GAP-004" - finding_id: GAP-011 reason: "Mitigated in P4 assessment, control confirmed present" ``` **Validation Rules**: - `source_files.P5_threat_inventory.exists == false` → **BLOCKING**: Return to P5 - `count_conservation.conservation_verified == false` → **BLOCKING**: Recount and reconcile - `findings_consolidation.findings_not_mapped > 0` without reasons → **WARNING**: Document reasons **Count Conservation Failure Handling**: ``` IF conservation_sum != p5_total_threats: 1. List all P5 threats: extract threat_inventory.threats[].id 2. For each P5 threat, find its P6 disposition (verified/theoretical/pending/excluded) 3. Identify missing threats (in P5 but not in P6 disposition) 4. Add missing threats to appropriate category with explicit reason 5. Re-verify conservation formula 6. ONLY proceed if conservation_verified == true ``` ## Output Context → P7: `validated_risks` {risk_summary{}, risk_details[], poc_details[], attack_paths[], attack_chains[]} --- ## Core Analysis Goal Consolidate ALL findings from P1-P5, perform deep validation from attacker's perspective, design attack paths and POC code. This is NOT mitigation - focus on VALIDATING that risks are exploitable. --- ## Knowledge Reference **Query Commands**: ```bash # Attack path analysis $SKILL_PATH/kb --capec CAPEC-89 --attack-chain $SKILL_PATH/kb --attack-technique T1078 $SKILL_PATH/kb --check-kev CVE-2024-XXXX # Verification tests $SKILL_PATH/kb --stride-tests S $SKILL_PATH/kb --cwe-tests CWE-89 $SKILL_PATH/kb --wstg-category ATHN ``` ### KB Usage Logging (Recommended) **Record KB queries made during risk validation**: ```yaml # In P6_validated_risks.yaml - RECOMMENDED section kb_usage_log: attack_chain_queries: - capec: CAPEC-194 query: "--capec CAPEC-194 --attack-chain" risks_informed: [VR-001] - capec: CAPEC-66 query: "--capec CAPEC-66 --attack-chain" risks_informed: [VR-003] attack_technique_queries: - technique: T1078 query: "--attack-technique T1078" attack_paths_informed: [AP-001] verification_queries: - category: WSTG-ATHN query: "--wstg-category ATHN" pocs_informed: [POC-001, POC-002] - cwe: CWE-89 query: "--cwe-tests CWE-89" pocs_informed: [POC-003] coverage: risks_with_capec_reference: 10 risks_with_attack_reference: 8 pocs_with_wstg_reference: 5 total_verified_risks: 15 kb_coverage_percentage: 66.7 ``` **Validation Rule** (WARNING only): - `kb_coverage_percentage < 40%` triggers WARNING - consider querying attack techniques and WSTG --- ## Consolidation Process ### Step 1: Gather All Findings Read ALL phase data files and extract findings: ```bash # Required reads from phase data files .phase_working/{SESSION_ID}/data/P1_project_context.yaml → architecture_findings .phase_working/{SESSION_ID}/data/P2_dfd_elements.yaml → dataflow_findings .phase_working/{SESSION_ID}/data/P3_boundary_context.yaml → boundary_findings .phase_working/{SESSION_ID}/data/P4_security_gaps.yaml → security_gaps .phase_working/{SESSION_ID}/data/P5_threat_inventory.yaml → threat_inventory ``` | Source | Finding Types | ID Format | Data Block | |--------|---------------|-----------|------------| | P1 | Architecture discoveries | F-P1-xxx | `architecture_findings` | | P2 | DFD/dataflow issues | F-P2-xxx | `dataflow_findings` | | P3 | Boundary issues | F-P3-xxx | `boundary_findings` | | P4 | Security gaps | GAP-xxx | `security_gaps` | | P5 | STRIDE threats | T-xxx | `threat_inventory` | ### Step 2: Cluster Related Findings Group findings that relate to the same vulnerability: ```yaml clustering_rules: same_element: "Findings targeting same DFD element (P-xxx, DS-xxx, DF-xxx)" same_boundary: "Findings at same trust boundary crossing" data_flow_chain: "Findings along same data flow path" control_chain: "Findings in same security control chain" attack_path: "Findings that form attack path steps" ``` ### Step 3: Deduplicate and Merge Similar threats targeting the same vulnerability should be merged into a single ValidatedRisk with multiple `threat_refs` and `finding_refs`. ```yaml # Example: Multiple findings merged into one VR validated_risk: id: VR-001 threat_refs: [T-S-P-001-001, T-E-P-001-002] # From P5 finding_refs: [F-P1-003, F-P2-007, GAP-002] # From P1-P4 ``` ### Step 4: Validate Each Risk For each potential risk: 1. **Assess exploitability**: Can it actually be exploited? 2. **Design attack path**: What steps would an attacker take? 3. **Create POC**: How would exploitation work? 4. **Determine status**: verified/theoretical/pending/excluded ### Step 5: Verify Count Conservation ``` P5.threat_inventory.total = verified + theoretical + pending + excluded ``` All findings (F-P1-xxx, F-P2-xxx, F-P3-xxx, GAP-xxx, T-xxx) must be: - Referenced in at least one VR's `threat_refs[]` or `finding_refs[]`, OR - Marked as `excluded` with documented reason --- ## Verification Status Types | Status | Symbol | Meaning | Criteria | |--------|--------|---------|----------| | verified | ✅ | POC executed successfully | Attack reproduced | | pending | ⚠️ | Needs manual verification | Requires specific environment | | theoretical | 📋 | Code analysis shows exploitable | Not yet tested | | excluded | ❌ | Confirmed not exploitable | Mitigations exist | --- ## Count Conservation Rule ``` P5.threat_inventory.total = verified + theoretical + pending + excluded ``` **Every threat from P5 MUST be accounted for in P6**: - Either in a ValidatedRisk's `threat_refs[]` - Or marked as `excluded` with documented reason --- ## Output Structure (5 Parts) ### Part 1: Risk Summary ```yaml risk_summary: total_identified: 85 # From P5 total_verified: 12 # ✅ POC confirmed total_pending: 8 # ⚠️ Needs verification total_theoretical: 45 # 📋 Code analysis total_excluded: 20 # ❌ Not exploitable verification_rate: "76%" # (verified+theoretical)/total risk_by_severity: critical: 5 high: 12 medium: 25 low: 23 risk_by_stride: S: 12 T: 18 R: 8 I: 22 D: 10 E: 15 ``` ### Part 2: POC Details Every Critical/High threat MUST have a complete POC: ```yaml poc_details: - poc_id: POC-001 threat_ref: T-S-P-001-001 stride_type: S verification_status: verified exploitation_difficulty: medium prerequisites: - "Valid user session" - "Knowledge of target user ID" vulnerability_location: file_path: "src/api/auth.py" function_name: "verify_token" line_number: 45 vulnerable_code: | def verify_token(token): # Missing signature verification return jwt.decode(token, options={"verify_signature": False}) exploitation_steps: - "Obtain any valid JWT token" - "Modify payload to change user_id" - "Send modified token to API" poc_code: | import jwt import requests # 1. Get valid token original_token = "eyJ..." # 2. Decode without verification payload = jwt.decode(original_token, options={"verify_signature": False}) # 3. Modify user_id payload["user_id"] = "admin" # 4. Re-encode (any key works) malicious_token = jwt.encode(payload, "any_key", algorithm="HS256") # 5. Use malicious token response = requests.get( "https://target.com/api/user/profile", headers={"Authorization": f"Bearer {malicious_token}"} ) print(response.json()) expected_result: | {"status": "success", "user": {"id": "admin", "role": "administrator"}} actual_result: | Successfully retrieved admin profile risk_assessment: complexity: medium attack_vector: network impact_scope: user_data data_sensitivity: high ``` ### Part 3: Risk Details ```yaml risk_details: - risk_id: VR-001 title: "JWT Signature Verification Bypass" threat_refs: [T-S-P-001-001, T-E-P-001-002] # MANDATORY finding_refs: [GAP-001] stride_types: [S, E] priority: P0 cvss_score: 9.8 cvss_vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" location: files: ["src/api/auth.py"] elements: [P-001] trust_boundary: TB-001 detailed_analysis: | The application uses PyJWT to decode tokens but disables signature verification, allowing attackers to forge tokens. root_cause: | Developer explicitly disabled verification for "debugging" and forgot to re-enable it. related_cwe: CWE-287 related_capec: CAPEC-194 related_attack: T1078 related_poc: POC-001 validation: status: verified poc_available: true test_cases: - "WSTG-ATHN-04: JWT Token Forgery" ``` ### Part 4: Attack Path Matrix ```yaml attack_path_matrix: - path_id: AP-001 path_name: "Auth Bypass → Admin Access" entry_point: "Public API" key_nodes: [P-001, P-002] final_target: "Admin Functions" feasibility_score: 9.2 detection_difficulty: low priority_fix: true related_risks: [VR-001] - path_id: AP-002 path_name: "SQL Injection → Data Exfiltration" entry_point: "Search API" key_nodes: [P-003, DS-001] final_target: "User Database" feasibility_score: 7.5 detection_difficulty: medium priority_fix: true related_risks: [VR-003] ``` ### Part 5: Attack Chains ```yaml attack_chains: - chain_id: AC-001 chain_name: "Privilege Escalation Chain" entry_point: "Public API" target: "Administrator Access" impact_scope: "Complete System Control" difficulty: medium related_threats: [T-S-P-001-001, T-E-P-001-002] steps: - step: 1 title: "Initial Access" source: "Attacker" target: "API Gateway" action: "Obtain valid JWT token" code_location: "api/routes.py:120" data_change: "Acquire session token" - step: 2 title: "Token Manipulation" source: "Attacker" target: "JWT Token" action: "Modify user_id in payload" code_location: "N/A (client-side)" data_change: "Forged admin identity" - step: 3 title: "Privilege Escalation" source: "API Gateway" target: "Auth Service" action: "Submit forged token" code_location: "auth/verify.py:45" data_change: "Gain admin role" attack_flow_diagram: | ┌─────────────────────────────────────────────────────────────────┐ │ Attack Chain: Privilege Escalation │ ├─────────────────────────────────────────────────────────────────┤ │ Step 1: Initial Access │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ Attacker ──→ API Gateway │ │ │ │ Action: Obtain valid JWT token │ │ │ │ Location: api/routes.py:120 │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Step 2: Token Manipulation │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ Attacker ──→ JWT Token │ │ │ │ Action: Modify user_id in payload │ │ │ │ Location: Client-side manipulation │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Step 3: Privilege Escalation │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ API Gateway ──→ Auth Service │ │ │ │ Action: Submit forged token, gain admin role │ │ │ │ Location: auth/verify.py:45 │ │ │ └───────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Result: Administrator access achieved │ └─────────────────────────────────────────────────────────────────┘ prerequisites: - "Network access to API" - "Ability to create user account" exploitation_commands: | # Step 1: Get valid token TOKEN=$(curl -s -X POST https://target/api/login \ -d '{"user":"test","pass":"test123"}' | jq -r '.token') # Step 2: Forge admin token ADMIN_TOKEN=$(python3 jwt_forge.py --token $TOKEN --user admin) # Step 3: Access admin functions curl -H "Authorization: Bearer $ADMIN_TOKEN" \ https://target/api/admin/users ioc_indicators: - "JWT tokens with mismatched signature" - "Rapid role changes in same session" defense_recommendations: - cutpoint: "Step 2" recommendation: "Enable JWT signature verification" - cutpoint: "Step 3" recommendation: "Implement token binding to IP/device" ``` --- ## Report Template ```markdown # P6: Risk Validation ## Executive Summary | Metric | Count | |--------|-------| | Total Threats (from P5) | N | | Verified (✅) | N | | Pending (⚠️) | N | | Theoretical (📋) | N | | Excluded (❌) | N | | Verification Rate | N% | ## Count Conservation Check - P5 Total: N - P6 Total (V+Th+P+E): N - Status: ✅ PASS / ❌ FAIL ## Critical Risks ### VR-001: JWT Signature Verification Bypass [Full risk detail with POC] ## Attack Path Analysis ### AP-001: Auth Bypass → Admin Access [Attack path with feasibility score] ## Attack Chains ### AC-001: Privilege Escalation Chain [Full attack chain with ASCII diagram] ## Validated Risks Inventory [yaml:validated_risks block] ``` --- ## SAST-Assisted Validation (Optional Enhancement) > **Reference**: @knowledge/sast-rules.yaml for tool configurations and STRIDE mappings. ### When to Use SAST Tools | Condition | Recommended Tool | Purpose | |-----------|------------------|---------| | Validating T-T-* (Tampering) | Semgrep `p/sql-injection`, `p/xss` | Find injection patterns | | Validating T-S-* (Spoofing) | Semgrep `p/jwt-security` | Auth bypass evidence | | Validating T-E-* (Elevation) | CodeQL dataflow | Trace privilege paths | | Searching secrets | Semgrep `p/secrets` | Hardcoded credential proof | ### LLM Decision Matrix 1. Check if SAST tools available (from P1_static_discovery.yaml `enhanced_tools`) 2. Map threat type to relevant SAST rules (see stride_sast_mapping in sast-rules.yaml) 3. Execute targeted scan if applicable 4. Integrate findings into `poc_details.tool_evidence` ### SAST Evidence Integration ```yaml poc_details: - poc_id: POC-001 # ... other fields ... tool_evidence: tool: "semgrep" rule: "p/sql-injection" command_executed: "semgrep --config p/sql-injection --json {project_path}" findings: - file: "src/api/search.py" line: 45 rule_id: "python.sqlalchemy.security.sqlalchemy-execute-raw-query" message: "Detected raw SQL query with user input" interpretation: "Confirms T-T-DS-001-001 is exploitable via SQL injection" ``` --- ## Attack Tree Generation (Optional Enhancement) > **Design Principle**: Use Prompt extension, NOT code templates. LLM generates attack trees using reasoning. ### When to Generate Attack Trees Generate attack trees when: 1. Multiple related risks form an attack chain 2. Complex privilege escalation paths identified 3. User explicitly requests attack tree visualization 4. Critical risks require comprehensive attack path documentation ### Attack Tree Mermaid Output Format ```mermaid graph TD %% Attack Tree: [Goal Description] %% Generated from: VR-xxx, T-xxx threat analysis ROOT["🎯 GOAL: Obtain Admin Access"] %% OR nodes: Any child success achieves parent goal ROOT --> OR1["OR: Authentication Bypass"] ROOT --> OR2["OR: Privilege Escalation"] %% AND nodes: All children required for parent goal OR1 --> AND1["AND: Token Forgery Chain"] %% LEAF nodes: Concrete attack steps AND1 --> LEAF1["LEAF: Obtain valid JWT
Cost: Low | Prob: 0.9"] AND1 --> LEAF2["LEAF: Modify payload
Cost: Low | Prob: 0.8"] AND1 --> LEAF3["LEAF: Bypass signature check
Cost: Low | Prob: 0.7
Ref: T-S-P-001-001"] OR2 --> LEAF4["LEAF: IDOR on /api/users/{id}
Cost: Low | Prob: 0.6
Ref: T-E-P-002-001"] OR2 --> LEAF5["LEAF: SQL injection escalation
Cost: Medium | Prob: 0.5
Ref: T-T-DS-001-001"] %% Styling style ROOT fill:#ff6b6b,stroke:#333,stroke-width:2px style OR1 fill:#ffd93d,stroke:#333 style OR2 fill:#ffd93d,stroke:#333 style AND1 fill:#ff9f43,stroke:#333 style LEAF1 fill:#51cf66,stroke:#333 style LEAF2 fill:#51cf66,stroke:#333 style LEAF3 fill:#51cf66,stroke:#333 style LEAF4 fill:#51cf66,stroke:#333 style LEAF5 fill:#51cf66,stroke:#333 ``` ### Attack Tree Node Types | Node Type | Symbol | Meaning | Style | |-----------|--------|---------|-------| | ROOT | 🎯 | Attack goal | Red (#ff6b6b) | | OR | - | Any child success | Yellow (#ffd93d) | | AND | - | All children required | Orange (#ff9f43) | | LEAF | - | Concrete attack step | Green (#51cf66) | ### LEAF Node Format Each LEAF node should include: - Attack step description - Cost: Low/Medium/High - Probability: 0.0-1.0 - Ref: Related threat ID (T-xxx or VR-xxx) ### Attack Tree YAML Schema ```yaml attack_trees: - tree_id: AT-001 goal: "Obtain Administrator Access" related_risks: [VR-001, VR-003] related_threats: [T-S-P-001-001, T-E-P-002-001, T-T-DS-001-001] total_paths: 3 highest_probability_path: 0.504 # 0.9 * 0.8 * 0.7 nodes: - id: ROOT type: goal description: "Obtain Admin Access" children: [OR1, OR2] - id: OR1 type: or description: "Authentication Bypass" children: [AND1] - id: AND1 type: and description: "Token Forgery Chain" children: [LEAF1, LEAF2, LEAF3] - id: LEAF1 type: leaf description: "Obtain valid JWT" cost: low probability: 0.9 threat_ref: null # ... more nodes mermaid_diagram: | [Full Mermaid code block] attack_paths: - path_id: "ROOT→OR1→AND1→[LEAF1,LEAF2,LEAF3]" combined_probability: 0.504 total_cost: low cutpoint_recommendation: "LEAF3 - Enable JWT signature verification" ``` ### Integration with Report Include attack trees in P6 report: ```markdown ## Attack Tree Analysis ### AT-001: Obtain Administrator Access **Goal**: Gain full administrative control over the application **Attack Paths Identified**: 3 **Highest Probability Path**: 50.4% (Token Forgery Chain) [Mermaid diagram here] **Recommended Cutpoints**: 1. LEAF3 (Bypass signature check) - Enable JWT signature verification 2. LEAF4 (IDOR) - Implement proper authorization checks ``` --- ## Findings Coverage Verification (CRITICAL) **P6 MUST verify complete coverage of ALL P1-P5 findings**: ```yaml # In P6_validated_risks.yaml - REQUIRED section findings_coverage_verification: # Input References input_refs: p1_file: "P1_project_context.yaml" p2_file: "P2_dfd_elements.yaml" p3_file: "P3_boundary_context.yaml" p4_file: "P4_security_gaps.yaml" p5_file: "P5_threat_inventory.yaml" # P1 Architecture Findings Coverage p1_findings: total_findings: 0 # Count of F-P1-xxx from P1 (if any) findings_in_vr_refs: 0 # Referenced in some VR.finding_refs findings_excluded: 0 # In excluded_findings with reason coverage_percentage: 100 # (in_refs + excluded) / total uncovered_findings: [] # MUST be empty # P2 Data Flow Findings Coverage p2_findings: total_findings: 0 # Count of F-P2-xxx from P2 (if any) findings_in_vr_refs: 0 findings_excluded: 0 coverage_percentage: 100 uncovered_findings: [] # P3 Boundary Findings Coverage p3_findings: total_findings: 0 # Count of F-P3-xxx from P3 (if any) findings_in_vr_refs: 0 findings_excluded: 0 coverage_percentage: 100 uncovered_findings: [] # P4 Security Gaps Coverage p4_gaps: total_gaps: 12 # Count of GAP-xxx from P4 gaps_in_vr_refs: 10 # Referenced in some VR.finding_refs gaps_excluded: 2 # In excluded_findings with reason coverage_percentage: 100 # MUST be 100% uncovered_gaps: [] # MUST be empty # P5 Threats Coverage (existing count conservation) p5_threats: total_threats: 45 # From P5.threat_inventory.summary.total threats_in_vr_refs: 40 # Referenced in some VR.threat_refs threats_excluded: 5 # In excluded_findings with reason coverage_percentage: 100 # MUST be 100% uncovered_threats: [] # MUST be empty # Count Conservation Check verified_count: 15 theoretical_count: 20 pending_count: 5 excluded_count: 5 conservation_check: true # verified + theoretical + pending + excluded == total # Overall Coverage overall: total_findings: 57 # Sum of all finding types findings_covered: 57 # In VR refs or excluded coverage_percentage: 100 # MUST be 100% conservation_verified: true # P5 count conservation passed # Excluded Findings Documentation excluded_findings: - id: GAP-011 source_phase: P4 exclusion_reason: "Already mitigated in production" evidence: "Verified in code review 2026-01-15" - id: T-S-P-005-001 source_phase: P5 exclusion_reason: "False positive - auth check exists at caller" evidence: "See src/middleware/auth.py:45" ``` **Validation Rules**: - Every F-P1-xxx finding must be in some VR's `finding_refs[]` OR in `excluded_findings[]` - Every F-P2-xxx finding must be in some VR's `finding_refs[]` OR in `excluded_findings[]` - Every F-P3-xxx finding must be in some VR's `finding_refs[]` OR in `excluded_findings[]` - Every GAP-xxx must be in some VR's `finding_refs[]` OR in `excluded_findings[]` - Every T-xxx must be in some VR's `threat_refs[]` OR in `excluded_findings[]` - Count Conservation: `P5.total == verified + theoretical + pending + excluded` **BLOCKING**: `coverage_percentage < 100%` for any phase's findings **BLOCKING**: `conservation_verified == false` --- ## POC to TestCase Mapping (P6→P8 Bridge) P6 generates POCs; P8 requires TestCases. This mapping ensures test coverage: ```yaml # In P6_validated_risks.yaml - REQUIRED section poc_to_testcase_mapping: description: "Mapping from POC-xxx to TC-xxx for P8 test case generation" mappings: - poc_id: POC-001 poc_title: "JWT Token Forgery" suggested_tc_type: manual_pentest suggested_tc_priority: critical tc_prerequisites: - "Access to valid user JWT" - "Burp Suite or jwt_tool" tc_verification: "Admin access obtained without valid credentials" - poc_id: POC-002 poc_title: "SQL Injection in Search" suggested_tc_type: automated_scan suggested_tc_priority: high tc_prerequisites: - "sqlmap installed" - "Access to search endpoint" tc_verification: "Database data exfiltrated via error-based SQLi" coverage_summary: total_pocs: 0 pocs_with_tc_mapping: 0 coverage_percentage: 100 # pocs_with_tc_mapping / total_pocs * 100 ``` **P8 Consumption**: P8 reads `poc_to_testcase_mapping` and generates TC-xxx entities with `poc_ref` field populated. --- ## Validation Gates | Check | Severity | |-------|----------| | yaml:validated_risks block present | BLOCKING | | findings_coverage_verification present | BLOCKING | | p4_gaps.coverage_percentage == 100% | BLOCKING | | p5_threats.coverage_percentage == 100% | BLOCKING | | Count conservation formula balances | BLOCKING | | All excluded_findings have documented reasons | BLOCKING | | Critical/High risks have POC details | BLOCKING | | attack_chains section present | WARNING | | ASCII diagrams in attack chains | WARNING | | Attack trees for complex risk clusters | INFO | | SAST evidence for injection threats | INFO | --- ## Completion Checklist Before marking Phase 6 complete: **Findings Coverage Verification**: - [ ] `findings_coverage_verification` section present in YAML - [ ] P1-P3 findings coverage verified (if any findings exist) - [ ] P4 gaps coverage_percentage == 100% - [ ] P5 threats coverage_percentage == 100% - [ ] All excluded_findings have documented reasons and evidence - [ ] conservation_verified == true (P5 count conservation) **Risk Validation**: - [ ] All P5 threats accounted for - [ ] Count conservation verified - [ ] yaml:validated_risks present - [ ] yaml:poc_details for Critical/High - [ ] yaml:attack_chains present - [ ] ASCII attack flow diagrams included - [ ] Validation passed **Optional Enhancements**: - [ ] Attack trees for complex risk clusters - [ ] SAST tool evidence for applicable threats --- **End of Phase 6 Instructions** (~550 lines, ~4.5K tokens)