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)
   • 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 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 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