cve-reachability-analyzer

# Post-Disclosure CVE Reachability Analyzer

## Overview

This skill performs static analysis of software repositories to determine whether disclosed CVEs in dependencies are reachable from the project's code. It analyzes import patterns, call chains, dynamic invocation, and configuration to classify each CVE's reachability with evidence-based justification.

## Workflow

### Step 1: Gather Input Information

Collect and validate the required information:

1. **Repository analysis**:
   - Identify programming language(s)
   - Locate dependency files (package.json, requirements.txt, pom.xml, etc.)
   - Understand project structure and entry points

2. **CVE information**:
   - CVE ID and description
   - Affected package name and version range
   - Vulnerable component (function/class/method)
   - Vulnerability type (injection, overflow, etc.)
   - Fixed version

3. **Configuration information** (optional):
   - Feature flags and their states
   - Build profiles (dev/staging/production)
   - Environment variables
   - Runtime configuration files

### Step 2: Verify Dependency Presence

Check if the vulnerable dependency exists in the project:

1. **Parse dependency files**:
   - Read language-specific dependency files (see [language_guide.md](references/language_guide.md))
   - Extract package names and version constraints
   - Build dependency tree (including transitive dependencies)

2. **Version matching**:
   - Compare installed version against vulnerable version range
   - Check if version falls within affected range
   - Identify if fixed version is available

3. **Early exit**:
   - If package not present → **Not Applicable**
   - If version not in vulnerable range → **Not Vulnerable**
   - Otherwise, proceed to Step 3

### Step 3: Analyze Import Patterns

Determine if vulnerable components are imported:

1. **Search for imports**:
   - Find all import/require/using statements for the vulnerable package
   - Check for direct imports of vulnerable function/class
   - Identify wildcard imports that may include vulnerable component
   - Look for aliased imports

2. **Language-specific patterns**:
   - Consult [language_guide.md](references/language_guide.md) for language-specific import syntax
   - Check for framework-specific import mechanisms (DI, auto-loading)

3. **Assessment**:
   - No imports found → Likely unreachable (but check dynamic loading in Step 5)
   - Imports found → Proceed to Step 4

### Step 4: Trace Call Chains

Identify if vulnerable code is invoked:

1. **Direct usage analysis**:
   - Search for call sites of vulnerable function/method
   - Find instantiations of vulnerable classes
   - Locate references to vulnerable symbols

2. **Indirect usage analysis**:
   - Trace calls through wrapper functions
   - Check for framework auto-invocation (middleware, event handlers, DI)
   - Identify callback registrations
   - Look for inheritance/interface implementations

3. **Build call graph**:
   - Map call chains from entry points to vulnerable code
   - Identify all paths that reach vulnerable component
   - Note the depth and complexity of call chains

4. **Use pattern library**:
   - Consult [reachability_patterns.md](references/reachability_patterns.md) for common patterns
   - Match observed patterns to known reachability scenarios

### Step 5: Analyze Dynamic Invocation

Check for dynamic code execution that may reach vulnerable code:

1. **Reflection/metaprogramming**:
   - Search for reflection APIs (Java: `Class.forName()`, Python: `getattr()`, etc.)
   - Check if vulnerable component could be invoked dynamically
   - Assess likelihood based on how constrained the dynamic calls are

2. **Dynamic loading**:
   - Look for dynamic imports (Python: `importlib`, JS: `require(variable)`)
   - Check plugin systems or extension mechanisms
   - Evaluate if vulnerable package could be loaded dynamically

3. **Eval and code generation**:
   - Search for `eval()`, `exec()`, `Function()` constructor
   - Check if vulnerable code could be executed through eval
   - Assess risk based on input sources

### Step 6: Evaluate Configuration Gates

Determine if vulnerable code is gated by configuration:

1. **Feature flags**:
   - Search for feature flag checks around vulnerable code
   - Determine flag states in production (if configuration provided)
   - Assess if flag could be enabled

2. **Environment-specific code**:
   - Check for environment conditionals (dev/staging/prod)
   - Determine which environments execute vulnerable code
   - Focus on production environment

3. **Build-time conditionals**:
   - Look for build profiles, compilation flags
   - Check if vulnerable code is included in production builds
   - Review preprocessor directives

4. **Runtime configuration**:
   - Check for configuration files that control code paths
   - Determine if vulnerable code path is enabled
   - Assess likelihood of configuration changes

### Step 7: Assess Code Path Reachability

Determine if the code path is actually executed:

1. **Dead code detection**:
   - Check for commented-out code
   - Identify unreachable branches (if False, etc.)
   - Find deprecated/unused functions with no callers

2. **Test-only code**:
   - Identify if usage is only in test files
   - Check for test-specific imports or mocks
   - Distinguish production vs. test code paths

3. **Error handling paths**:
   - Determine if vulnerable code is in error handlers
   - Assess likelihood of error conditions
   - Consider if error paths are reachable in practice

4. **Entry point analysis**:
   - Trace from application entry points (main, HTTP handlers, etc.)
   - Verify vulnerable code is on reachable paths from entry points
   - Consider application flow and typical execution paths

### Step 8: Classify Reachability

Apply classification criteria from [cve_analysis.md](references/cve_analysis.md):

**Likely Reachable** - All of:
- Vulnerable package is present in correct version range
- Vulnerable component is