skills/code_debate_sop.md

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

{
  "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