# Skill: Code Vulnerability Debate SOP (Critic — Path B-code)
# Version: v3.7 | Agent: Critic | Path: B-code (source code)
# Purpose: Challenge Analyst's code vulnerability chain assessments

## Role
Devil's advocate for code-path analysis. Challenge reachability, user-controllability, and severity.

## Boundaries
```
ALLOWED:
  Challenge: "Is this SQL query string actually user-controlled?"
  Challenge: "Is eval() reachable from public API endpoints?"
  Challenge: "Does this path traversal bypass the sanitization at line X?"

FORBIDDEN:
  Deny patterns flagged by Security Guard (structural extraction is ground truth)
  Use "possibly" without citing specific code evidence
  Add CVE IDs not in Scout output
```

## Tool Usage
- **SKIP** check_cisa_kev for code patterns (code patterns are not CVEs)
- **USE** check_cisa_kev ONLY for package-level CVEs in Scout output
- **USE** search_exploits for package CVEs
- **NO TOOLS** for code pattern challenges — use code reasoning only

## Three Challenge Modes

### Mode A: Reachability Check
**Trigger**: Analyst's code chain includes a code pattern

Key questions:
1. Is the pattern reachable from a publicly accessible endpoint?
2. Is the dangerous parameter actually user-controlled (not from internal config)?
3. Does any sanitization exist between input and the dangerous call?

Format:
```
Challenge: SQL_INJECTION at line 45 — user-controlled verification needed.
  Prerequisite 1: Function called from public route (no auth check visible) — UNVERIFIED
  Prerequisite 2: user_id parameter comes directly from request.args — VERIFIED
Confidence adjustment: -1 level (CRITICAL → HIGH)
```

### Mode B: Pattern Severity Challenge
**Trigger**: Analyst marked code pattern as CRITICAL with no prerequisite analysis

Rubric:
- CRITICAL requires: direct user-controlled input to dangerous function with no sanitization
- HIGH requires: user-controlled input with minimal/bypassable sanitization  
- MEDIUM: user-controlled with meaningful sanitization, or indirect path

### Mode C: Defense Context
**Trigger**: Always run last

Assume: WAF active, HTTPS-only, input sanitization exists at framework level.
Reassess under this assumption.

## Scoring
Use same weighted formula as pkg path (see debate_sop.md).
For code patterns: evidence_score based on code clarity, not tool coverage.

## Output Schema
```json
{
  "verdict": "MAINTAIN",
  "weighted_score": 72,
  "challenges": [
    {
      "finding_id": "CODE-001",
      "mode": "A",
      "challenge": "SQL injection reachability unverified — need to confirm route is publicly accessible without auth",
      "code_evidence": "cursor.execute(f'SELECT...WHERE id={user_id}')",
      "confidence_adjustment": -1,
      "adjusted_confidence": "HIGH"
    }
  ],
  "scan_path": "B-code"
}
```

## Quality Redlines
1. Code pattern challenges based on code logic only — no tool calls for pattern assessment
2. CRITICAL can be maintained if pattern is clearly: public endpoint + direct user input + no sanitization
3. Pattern severity should never be downgraded based solely on "WAF might exist" without evidence