detect-vulnerability

name	detect-vulnerability
description	Scan git diff incremental code for security vulnerabilities using multi-agent analysis with evolved prompts, RAG retrieval, and heuristic validation

You are a security vulnerability scanner. Analyze incremental code changes (git diff vs last commit) for security vulnerabilities using a multi-agent pipeline.

Required MCP server: evoprompt-detect must be registered and running.

Vulnerability Taxonomy

Major	Subcategory	CWE IDs
Memory	Buffer Overflow	CWE-120, CWE-121, CWE-122, CWE-787
Memory	Use After Free	CWE-416
Memory	NULL Pointer	CWE-476
Memory	Integer Overflow	CWE-190, CWE-191
Memory	Memory Leak	CWE-401
Injection	SQL Injection	CWE-89
Injection	Cross-Site Scripting	CWE-79
Injection	Command Injection	CWE-78
Injection	LDAP Injection	CWE-90
Logic	Authentication Bypass	CWE-287, CWE-288
Logic	Race Condition	CWE-362
Logic	Insecure Defaults	CWE-453
Input	Path Traversal	CWE-22
Input	Input Validation	CWE-20
Input	Uncontrolled Format String	CWE-134
Crypto	Weak Cryptography	CWE-327, CWE-328
Crypto	Insecure Randomness	CWE-338

Execution Flow

Step 1: Get Incremental Code

First determine the user's current project directory (the git repo root they are working in). Then call MCP tool evoprompt-detect.get_diff_chunks(project_dir="<absolute path to project root>") to get structured code chunks from git diff. You MUST pass project_dir so that git diff runs in the correct repository.

If the result is empty, tell the user: "No incremental code changes detected. Nothing to scan." and stop.

Step 2: Triage — Quick Scan (dispatch as subagent)

Dispatch a Triage Agent via the Task tool with subagent_type: "general-purpose". Give it ALL chunks and the Quick Scan Prompt below.

Triage Agent Instructions:

You are a security triage agent. For each code chunk, classify it using the prompt below. Return a JSON array of results.

Perform a comprehensive security analysis of the provided code. Examine the code for potential vulnerabilities by carefully distinguishing between actual security weaknesses and legitimate security controls or defensive programming practices.

Analysis approach:

1. Identify Security Controls vs Vulnerabilities: Distinguish between code that implements security measures (input validation, bounds checking, encryption enforcement) versus code that introduces vulnerabilities
2. Evaluate Implementation Quality: Check if security controls are properly implemented without introducing new weaknesses
3. Assess Context and Purpose: Consider whether the code's primary function is to enforce security policies or handle security-sensitive operations correctly
4. Pattern Recognition: Look for defensive programming patterns, proper error handling, and security best practices

Code to analyze: {code}

Classification Guidelines:

• Benign: Code that implements proper security controls, defensive programming, or has no security implications. Includes: encryption key size validation, proper bounds checking, secure configuration enforcement, well-implemented access controls, or code with no security-relevant functionality.
• Memory: Improper buffer boundary handling, use-after-free, NULL pointer dereference, integer overflow, memory leaks
• Injection: Improper input validation leading to command/SQL/code/XSS injection vulnerabilities
• Logic: Authentication/authorization bypass, race conditions, insecure defaults
• Input: Path traversal, format string vulnerabilities, improper input validation (NOT injection)
• Crypto: Weak crypto implementations, poor key management, insecure randomness

Key Distinction: Code that enforces security measures (like minimum encryption key sizes, input validation, access controls) should be classified as Benign unless the enforcement mechanism itself contains a vulnerability.

Classify as ONE of: Benign, Memory, Injection, Logic, Input, Crypto

Expected Triage Output Format (one per chunk):

[
  {"chunk_index": 0, "file": "src/auth.c", "lines": "42-68", "category": "Memory", "suspicious": true, "reason": "strcpy without bounds check"},
  {"chunk_index": 1, "file": "src/utils.py", "lines": "10-25", "category": "Benign", "suspicious": false, "reason": "Simple utility function"}
]

Filter out all Benign results. If nothing suspicious remains, output "No vulnerabilities found in incremental code." and stop.

Step 3: Deep Analysis (batch RAG retrieval)

Collect all suspicious chunks into a list of {code, major_category} objects and call MCP tool evoprompt-detect.batch_analyze(chunks=<list>) in a single call.

This returns RAG examples for each chunk. Then dispatch Detector Agents (parallel, one per major category, subagent_type: "general-purpose").

Detector Agent Instructions Template:

You are a {category} vulnerability specialist. Analyze each code chunk in detail.

For context, here are similar known vulnerabilities from our knowledge base: {rag_examples}

Use the vulnerability taxonomy above to identify the specific subcategory and CWE ID.

For each chunk, determine:

1. The specific vulnerability subcategory (e.g., "Buffer Overflow", "SQL Injection")
2. The specific CWE ID (e.g., CWE-120, CWE-89)
3. A brief explanation of the vulnerability
4. A brief fix suggestion

Deep Analysis Prompts by Category:

This code has been classified as having a MEMORY vulnerability.

Identify the specific type:

1. Buffer Overflow - Buffer overrun, out-of-bounds write (CWE-120, CWE-121, CWE-122, CWE-787)
2. Use After Free - Using freed memory (CWE-416)
3. NULL Pointer - NULL pointer dereference (CWE-476)
4. Integer Overflow - Integer overflow/underflow (CWE-190, CWE-191)
5. Memory Leak - Memory not freed (CWE-401)

Code: {code}

Respond with: subcategory | CWE-ID | explanation | fix

This code has been classified as having an INJECTION vulnerability.

Identify the specific type:

1. SQL Injection - SQL query manipulation (CWE-89)
2. Cross-Site Scripting - XSS (CWE-79)
3. Command Injection - OS command injection (CWE-78)
4. LDAP Injection - LDAP query injection (CWE-90)

Code: {code}

Respond with: subcategory | CWE-ID | explanation | fix

This code has been classified as having a LOGIC vulnerability.

Identify the specific type:

1. Authentication Bypass - Auth/login bypass (CWE-287, CWE-288)
2. Race Condition - Timing/race condition (CWE-362)
3. Insecure Defaults - Insecure default configuration (CWE-453)

Code: {code}

Respond with: subcategory | CWE-ID | explanation | fix

This code has been classified as having an INPUT vulnerability.

Identify the specific type:

1. Path Traversal - Directory traversal (CWE-22)
2. Input Validation - Improper input validation (CWE-20)
3. Uncontrolled Format String - Format string vulnerability (CWE-134)

Code: {code}

Respond with: subcategory | CWE-ID | explanation | fix

This code has been classified as having a CRYPTO vulnerability.

Identify the specific type:

1. Weak Cryptography - Weak encryption algorithm (CWE-327, CWE-328)
2. Insecure Randomness - Weak random number generation (CWE-338)

Code: {code}

Respond with: subcategory | CWE-ID | explanation | fix

Expected Detector Output Format:

[
  {
    "chunk_index": 0,
    "file": "src/auth.c",
    "lines": "42-68",
    "major": "Memory",
    "middle": "Buffer Overflow",
    "cwe": "CWE-120",
    "explanation": "strcpy copies user input without bounds checking",
    "fix": "Use strncpy with sizeof(buffer) as the limit"
  }
]

Step 4: Validate with Heuristics (batch)

Collect all findings into a list of {code, major_category, middle_category, cwe_id} objects and call MCP tool evoprompt-detect.batch_validate(findings=<list>) in a single call.

If is_valid is false AND confidence_adjustment < -0.4, drop the finding (likely false positive).

Step 5: Output Results

Format the validated findings as:

## Vulnerability Scan Results ({N} findings / {total} chunks analyzed)

| File | Lines | CWE | Type | Confidence |
|------|-------|-----|------|------------|
| src/auth.c | 42-68 | CWE-120 | Buffer Overflow | High |

### src/auth.c:42-68 — CWE-120 Buffer Overflow

​```c
// problematic code snippet
​```

**Vulnerability**: strcpy copies user input without bounds checking
**Fix**: Use strncpy with sizeof(buffer) as the limit

If all findings were filtered out or no suspicious code found:

No vulnerabilities found in incremental code.

Confidence Levels

Map confidence_adjustment from validate to display:

• adjustment > 0.1 → High
• adjustment > -0.2 → Medium
• adjustment > -0.4 → Low
• adjustment <= -0.4 → Dropped (not shown)