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:
2. Identify programming language(s)
3. Locate dependency files (package.json, requirements.txt, pom.xml, etc.)
4. Understand project structure and entry points

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

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

Step 2: Verify Dependency Presence

Check if the vulnerable dependency exists in the project:

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

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

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

Step 3: Analyze Import Patterns

Determine if vulnerable components are imported:

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

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

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

Step 4: Trace Call Chains

Identify if vulnerable code is invoked:

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

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

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

1. Use pattern library:
2. Consult [reachability_patterns.md](references/reachability_patterns.md) for common patterns
3. 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:
2. Search for reflection APIs (Java: Class.forName(), Python: getattr(), etc.)
3. Check if vulnerable component could be invoked dynamically
4. Assess likelihood based on how constrained the dynamic calls are

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

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

Step 6: Evaluate Configuration Gates

Determine if vulnerable code is gated by configuration:

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

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

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

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

Step 7: Assess Code Path Reachability

Determine if the code path is actually executed:

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

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

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

1. Entry point analysis:
2. Trace from application entry points (main, HTTP handlers, etc.)
3. Verify vulnerable code is on reachable paths from entry points
4. 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 imported (directly or via wildcard)
• Vulnerable code is called (directly or indirectly)
• Code path is in production code (not tests/dead code)
• No configuration gates, or gates are enabled in production

Possibly Reachable - One or more of:

• Indirect usage through wrappers or frameworks
• Dynamic invocation (reflection, eval, dynamic imports)
• Configuration-gated (unclear if enabled in production)
• Transitive dependency (not direct)
• Framework auto-invocation (DI, middleware)

Likely Unreachable - One or more of:

• Package imported but vulnerable component not used
• Code path is test-only or dead code
• Configuration gate is disabled in production
• Vulnerable component in unused module

Step 9: Generate Output

For each CVE, provide comprehensive assessment:

1. Classification: Likely Reachable / Possibly Reachable / Likely Unreachable

1. Confidence level: High / Medium / Low

1. Supporting evidence:
2. Import locations (file:line)
3. Call paths from entry points to vulnerable code
4. Configuration assumptions
5. Dynamic invocation patterns found

1. Reasoning:
2. Explain why this classification was chosen
3. Describe the analysis performed
4. Note any assumptions made

1. Uncertainty factors:
2. What is unknown or unclear
3. What additional information would help
4. Limitations of static analysis

1. Recommendations:
2. Suggested next steps (upgrade, investigate, monitor)
3. Additional verification needed
4. Mitigation options if upgrade not possible

Output Format

Structure the output as follows:

## CVE Reachability Analysis for [Repository Name]

### Summary
- Total CVEs analyzed: X
- Likely reachable: X
- Possibly reachable: X
- Likely unreachable: X

---

### CVE-YYYY-XXXXX: [Vulnerability Title]

**Package**: package-name
**Affected versions**: < X.Y.Z
**Installed version**: X.Y.Z
**Vulnerable component**: `function_name()` or `ClassName`

**Classification**: Likely Reachab