# Exploitability Analyzer

> Assess whether discovered vulnerabilities are actually exploitable in your application context using CVSS scoring, attack path analysis, reachability.

- Skill: `yigityildiz0/exploitability-analyzer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yigityildiz0/exploitability-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yigityildiz0/exploitability-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yigityildiz0 (https://skillmd.com/u/yigityildiz0)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yigityildiz0/exploitability-analyzer

---


# Exploitability Analyzer

Evaluate discovered vulnerabilities in their actual deployment and code context to determine real-world exploitability, enabling teams to focus remediation efforts on vulnerabilities that pose genuine risk rather than chasing every CVE equally.

## When to Use This Skill

Use this skill when you need to:

- Triage a large number of vulnerability scan findings and determine which ones matter
- Assess whether a specific CVE is exploitable given your application architecture
- Build a risk-prioritized remediation plan from scanner output
- Justify risk acceptance decisions to auditors or security reviewers
- Determine if compensating controls reduce or eliminate exploitability
- Evaluate attack paths from network boundary to vulnerable component
- Differentiate between theoretical vulnerabilities and practical threats
- Prepare vulnerability assessment reports for stakeholders
- Reduce false-positive noise from automated scanning tools

**Trigger phrases**: "is this exploitable", "exploitability assessment", "vulnerability triage", "risk prioritization", "CVSS analysis", "attack path analysis", "compensating controls", "false positive analysis", "vulnerability context"

## What This Skill Does

### Core Capabilities

- **CVSS Contextual Scoring**: Adjust base CVSS scores using temporal and environmental metrics specific to your deployment
- **Attack Path Analysis**: Map the steps an attacker would need to reach and exploit a vulnerable component
- **Reachability Analysis**: Determine if vulnerable code paths are actually invoked by your application
- **Compensating Controls Assessment**: Evaluate whether existing security controls mitigate or block exploitation
- **Risk Prioritization**: Produce a ranked list of vulnerabilities by actual exploitability, not just severity
- **Exploitation Prerequisite Mapping**: Identify what conditions must be true for a vulnerability to be exploitable
- **False Positive Identification**: Flag vulnerabilities that cannot be exploited in context

### Exploitability Factors Framework

The analysis evaluates each vulnerability across six dimensions:

| Factor | Description | Impact on Exploitability |
|--------|-------------|--------------------------|
| Attack Vector | Network, Adjacent, Local, Physical | Remote = higher risk |
| Attack Complexity | Conditions beyond attacker control | High complexity = lower risk |
| Privileges Required | Authentication level needed | None required = higher risk |
| User Interaction | Does exploitation need user action | No interaction = higher risk |
| Reachability | Is vulnerable code actually called | Unreachable = not exploitable |
| Compensating Controls | WAF, network segmentation, etc. | Strong controls = lower risk |

### Analysis Methodology

```
Vulnerability Discovery
        |
        v
Phase 1: Contextual CVSS Scoring
        |
        v
Phase 2: Reachability Analysis
        |
        v
Phase 3: Attack Path Mapping
        |
        v
Phase 4: Compensating Controls Review
        |
        v
Phase 5: Exploitation Prerequisite Check
        |
        v
Phase 6: Risk Prioritization & Reporting
```

## Instructions

### Phase 1: Gather Vulnerability Data

Collect all vulnerability findings from scanning tools and normalize them into a consistent format.

**Step 1.1: Normalize vulnerability records**

Create a structured record for each finding:

```json
{
  "id": "VULN-001",
  "cve": "CVE-2024-29041",
  "component": "express@4.18.2",
  "cvss_base": 6.1,
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
  "vulnerability_type": "Open Redirect",
  "affected_function": "res.redirect()",
  "scanner_source": "npm audit",
  "description": "Express.js open redirect via crafted URL parameter"
}
```

**Step 1.2: Parse the CVSS vector into individual metrics**

```python
def parse_cvss_vector(vector: str) -> dict:
    """Parse a CVSS 3.1 vector string into its component metrics."""
    metrics = {}
    parts = vector.replace("CVSS:3.1/", "").split("/")
    metric_names = {
        "AV": "attack_vector",
        "AC": "attack_complexity",
        "PR": "privileges_required",
        "UI": "user_interaction",
        "S": "scope",
        "C": "confidentiality",
        "I": "integrity",
        "A": "availability",
    }
    value_labels = {
        "AV": {"N": "Network", "A": "Adjacent", "L": "Local", "P": "Physical"},
        "AC": {"L": "Low", "H": "High"},
        "PR": {"N": "None", "L": "Low", "H": "High"},
        "UI": {"N": "None", "R": "Required"},
        "S": {"U": "Unchanged", "C": "Changed"},
        "C": {"N": "None", "L": "Low", "H": "High"},
        "I": {"N": "None", "L": "Low", "H": "High"},
        "A": {"N": "None", "L": "Low", "H": "High"},
    }
    for part in parts:
        key, value = part.split(":")
        metrics[metric_names.get(key, key)] = value_labels.get(key, {}).get(value, value)
    return metrics
```

### Phase 2: Reachability Analysis

Determine whether your application actually invokes the vulnerable function or code path.

**Step 2.1: Identify the vulnerable function or API**

For each CVE, determine the specific function, method, or code path that contains the vulnerability. Consult the CVE description, advisory, and any published proof-of-concept.

**Step 2.2: Trace call paths from application entry points**

Search the codebase for direct and indirect usage of the vulnerable function:

```bash
# Find direct usage of the vulnerable function
grep -rn "res\.redirect" --include="*.js" --include="*.ts" src/

# For dependency vulnerabilities, check if the vulnerable module is imported
grep -rn "require('express')\|from 'express'" --include="*.js" --include="*.ts" src/

# Check if the specific vulnerable method is called
# For transitive dependencies, trace the import chain
grep -rn "import.*from.*vulnerable-package" --include="*.ts" src/
```

**Step 2.3: Build a reachability determination**

```python
class ReachabilityResult:
    REACHABLE = "reachable"           # Vulnerable code is directly called
    INDIRECTLY_REACHABLE = "indirect" # Called through wrapper or framework
    UNREACHABLE = "unreachable"       # Vulnerable code path is never invoked
    CONDITIONAL = "conditional"       # Reachable only under specific conditions

def assess_reachability(cve_id: str, vulnerable_function: str, codebase_path: str) -> dict:
    """Assess whether a vulnerable function is reachable from application code."""
    result = {
        "cve": cve_id,
        "vulnerable_function": vulnerable_function,
        "reachability": ReachabilityResult.UNREACHABLE,
        "call_sites": [],
        "evidence": "",
        "conditions": [],
    }

    # Step 1: Search for direct invocations
    # Step 2: Trace through wrappers and abstractions
    # Step 3: Check if the invocation uses vulnerable parameters
    # Step 4: Determine conditional factors

    return result
```

**Step 2.4: Document unreachable vulnerabilities**

If the vulnerable function is never called, document the finding as a false positive with evidence:

```markdown
### VULN-001: CVE-2024-29041 (express open redirect)
- **Reachability**: UNREACHABLE
- **Evidence**: Application never calls `res.redirect()` with user-controlled input. All redirect targets are hardcoded constants in `src/routes/auth.js` lines 42, 67, 89.
- **Recommendation**: Low priority. Update express in next scheduled dependency refresh.
```

### Phase 3: Attack Path Analysis

For reachable vulnerabilities, map the complete attack path from external entry point to vulnerable component.

**Step 3.1: Identify entry points**

Enumerate all external-facing entry points that could reach the vulnerable component:

```yaml
entry_points:
  - type: HTTP endpoint
    path: /api/v1/users/redirect
    method: GET
    authentication: required
    input_source: query parameter "url"

  - type: HTTP endpoint
    path: /auth/callback
    method: GET
    authentication: none
    input_source: query parameter "redirect_uri"
```

**Step 3.2: Map the attack path**

Document each step an attacker must traverse:

```markdown
## Attack Path: CVE-2024-29041 via /auth/callback

1. **Entry Point**: GET /auth/callback?redirect_uri=<attacker_url>
2. **Authentication Gate**: None (public endpoint)
3. **Input Validation**: redirect_uri validated against allowlist in middleware
4. **Framework Processing**: Express route handler in auth.js:34
5. **Vulnerable Call**: res.redirect(req.query.redirect_uri) at auth.js:52
6. **Exploitation**: Attacker crafts URL to bypass allowlist validation

### Attack Prerequisites
- Attacker must craft a URL that bypasses the allowlist regex
- The allowlist regex in middleware uses a permissive pattern
- No URL normalization is performed before validation
```

**Step 3.3: Assess attack complexity in context**

```python
def assess_attack_complexity(attack_path: dict) -> str:
    """Determine the real-world attack complexity based on path analysis."""
    complexity_factors = []

    if attack_path["authentication"] != "none":
        complexity_factors.append("requires_authentication")

    if attack_path["input_validation"]:
        complexity_factors.append("must_bypass_validation")

    if attack_path["network_restrictions"]:
        complexity_factors.append("network_access_limited")

    if attack_path["rate_limiting"]:
        complexity_factors.append("rate_limited")

    if len(complexity_factors) == 0:
        return "LOW"
    elif len(complexity_factors) <= 2:
        return "MEDIUM"
    else:
        return "HIGH"
```

### Phase 4: Compensating Controls Assessment

Evaluate existing security controls that may reduce or eliminate exploitability.

**Step 4.1: Inventory existing controls**

Check for each category of compensating control:

```yaml
compensating_controls:
  network_layer:
    - name: WAF (Web Application Firewall)
      present: true
      rules_relevant: true
      effectiveness: "Blocks known open redirect patterns"

    - name: Network segmentation
      present: true
      details: "Vulnerable service is in private subnet, not internet-facing"

  application_layer:
    - name: Input validation
      present: true
      details: "URL allowlist middleware validates redirect targets"
      bypass_known: false

    - name: Content Security Policy
      present: true
      details: "CSP header restricts navigation targets"

    - name: Authentication requirement
      present: false
      details: "Endpoint is public"

  platform_layer:
    - name: Rate limiting
      present: true
      details: "100 requests per minute per IP"

    - name: Logging and alerting
      present: true
      details: "All redirects logged; anomaly detection active"
```

**Step 4.2: Evaluate control effectiveness**

```python
def evaluate_controls(controls: list[dict]) -> dict:
    """Evaluate the combined effectiveness of compensating controls."""
    mitigation_score = 0
    effective_controls = []
    ineffective_controls = []

    for control in controls:
        if control["present"] and control["rules_relevant"]:
            if control.get("bypass_known"):
                ineffective_controls.append(control["name"])
            else:
                effective_controls.append(control["name"])
                mitigation_score += control.get("weight", 1)

    return {
        "mitigation_score": mitigation_score,
        "effective_controls": effective_controls,
        "ineffective_controls": ineffective_controls,
        "overall_mitigation": (
            "STRONG" if mitigation_score >= 3
            else "MODERATE" if mitigation_score >= 1
            else "WEAK"
        ),
    }
```

### Phase 5: Contextual CVSS Rescoring

Adjust the base CVSS score using environmental and temporal metrics based on the analysis.

**Step 5.1: Apply environmental metrics**

```python
def calculate_environmental_score(base_cvss: float, context: dict) -> float:
    """Adjust CVSS base score with environmental context."""
    adjusted = base_cvss

    # Reduce for strong compensating controls
    if context["compensating_controls"]["overall_mitigation"] == "STRONG":
        adjusted *= 0.6
    elif context["compensating_controls"]["overall_mitigation"] == "MODERATE":
        adjusted *= 0.8

    # Reduce for limited reachability
    if context["reachability"] == "unreachable":
        adjusted = 0.0
    elif context["reachability"] == "conditional":
        adjusted *= 0.7

    # Reduce for high attack complexity in context
    if context["attack_complexity"] == "HIGH":
        adjusted *= 0.75

    # Adjust for asset criticality
    criticality_multiplier = {
        "critical": 1.2,
        "high": 1.0,
        "medium": 0.85,
        "low": 0.7,
    }
    adjusted *= criticality_multiplier.get(context["asset_criticality"], 1.0)

    return min(round(adjusted, 1), 10.0)
```

**Step 5.2: Apply temporal metrics**

Consider exploit maturity and patch availability:

```yaml
temporal_factors:
  exploit_code_maturity:
    not_defined: 1.0
    unproven: 0.91
    proof_of_concept: 0.94
    functional: 0.97
    high: 1.0

  remediation_level:
    not_defined: 1.0
    official_fix: 0.95
    temporary_fix: 0.96
    workaround: 0.97
    unavailable: 1.0

  report_confidence:
    not_defined: 1.0
    unknown: 0.92
    reasonable: 0.96
    confirmed: 1.0
```

### Phase 6: Risk Prioritization and Reporting

**Step 6.1: Generate the prioritized vulnerability report**

```markdown
# Exploitability Assessment Report

## Executive Summary
- **Total vulnerabilities scanned**: 47
- **Exploitable in context**: 8 (17%)
- **Partially mitigated**: 12 (26%)
- **Not exploitable / false positive**: 27 (57%)

## Critical Findings (Immediate Action Required)

### VULN-023: CVE-2024-XXXXX - SQL Injection in query builder
| Metric | Value |
|--------|-------|
| Base CVSS | 9.8 |
| Contextual CVSS | 9.2 |
| Reachability | REACHABLE |
| Attack Path | Public API -> Query Builder -> Database |
| Compensating Controls | WEAK (no parameterized queries) |
| Exploit Maturity | Functional exploit available |
| **Recommendation** | **Fix immediately. Apply parameterized queries.** |

## High Priority (Fix within 1 sprint)
...

## Medium Priority (Fix within 1 quarter)
...

## Accepted Risk / False Positives
...
```

**Step 6.2: Build the risk matrix visualization**

```
               EXPLOITABILITY
        Low    Medium    High    Critical
    +--------+---------+--------+---------+
 C  | Accept | Monitor | Plan   | Fix Now |
 r  +--------+---------+--------+---------+
 i  | Monitor| Plan    | Fix    | Fix Now |
 t  +--------+---------+--------+---------+
 i  | Plan   | Fix     | Fix Now| Fix Now |
 c  +--------+---------+--------+---------+
 a  | Fix    | Fix Now | Fix Now| Fix Now |
 l  +--------+---------+--------+---------+
```

**Step 6.3: Generate remediation recommendations**

For each exploitable vulnerability, provide specific remediation guidance:

```python
def generate_remediation(vuln: dict) -> dict:
    """Generate specific remediation guidance for an exploitable vulnerability."""
    return {
        "vulnerability": vuln["id"],
        "priority": vuln["contextual_priority"],
        "actions": [
            {
                "type": "immediate",
                "description": "Apply input validation to the affected endpoint",
                "effort": "low",
                "code_location": vuln["call_sites"],
            },
            {
                "type": "short_term",
                "description": f"Upgrade {vuln['component']} to patched version",
                "target_version": vuln["fixed_version"],
                "breaking_changes": vuln.get("breaking_changes", []),
            },
            {
                "type": "long_term",
                "description": "Implement defense-in-depth controls",
                "controls": ["WAF rule", "input sanitization library", "output encoding"],
            },
        ],
    }
```

### Automation Integration

Integrate exploitability analysis into CI/CD pipelines:

```yaml
# .github/workflows/exploitability-check.yml
name: Exploitability Analysis
on:
  schedule:
    - cron: "0 6 * * 1"  # Weekly Monday 6 AM
  workflow_dispatch:

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run vulnerability scanner
        run: |
          npm audit --json > scan-results.json

      - name: Assess exploitability
        run: |
          python scripts/exploitability-analyzer.py \
            --scan-results scan-results.json \
            --codebase-path ./src \
            --controls-config ./security/controls.yaml \
            --output report.md

      - name: Fail on critical exploitable findings
        run: |
          python scripts/check-exploitable-threshold.py \
            --report report.md \
            --max-critical 0 \
            --max-high 3
```

## Best Practices

- Always assess reachability before investing time in remediation; unreachable vulnerabilities carry near-zero practical risk
- Use contextual CVSS scoring rather than raw base scores; base scores assume worst-case deployment context
- Document compensating controls thoroughly so that risk acceptance decisions are auditable
- Re-evaluate exploitability when architecture changes, even if the vulnerability set has not changed
- Maintain an inventory of compensating controls and review their effectiveness quarterly
- Automate reachability analysis where possible to scale across large dependency trees
- Treat exploitability assessment as a living process, not a one-time activity
- Combine static analysis (code search) with dynamic analysis (runtime tracing) for higher confidence
- Keep the temporal metrics current; a vulnerability with no known exploit today may have one tomorrow
- Separate the roles of vulnerability discovery (automated scanners) and exploitability assessment (human-assisted analysis) to avoid confirmation bias

## Common Pitfalls

- **Treating all CVEs equally**: A CVSS 9.8 vulnerability that is unreachable poses less risk than a CVSS 5.0 vulnerability on a public endpoint. Always contextualize.
- **Ignoring transitive dependencies**: The vulnerable function may be called by a library you depend on, not by your code directly. Trace the full call chain.
- **Over-relying on compensating controls**: WAF rules and network segmentation are valuable, but they can be bypassed. Do not use them as a permanent substitute for fixing the underlying vulnerability.
- **Confusing "not exploitable now" with "not exploitable ever"**: Conditions change. A vulnerability that is currently unreachable may become reachable after a code change.
- **Skipping the attack path analysis**: Reachability alone is insufficient. The vulnerable function may be reachable but impossible to reach with attacker-controlled input.
- **Ignoring exploit maturity**: A vulnerability with a functional public exploit is far more dangerous than one that is only theoretically possible.
- **Failing to document risk acceptance**: When you decide not to fix a vulnerability, record the rationale, the conditions under which the decision should be revisited, and the responsible party.
- **Performing analysis in isolation**: Exploitability assessment should involve the development team (who understand the code), the security team (who understand threats), and the operations team (who understand the deployment environment).
- **Not updating the assessment**: When you patch one vulnerability, the compensating controls picture may change for other vulnerabilities. Re-evaluate related findings.
- **Ignoring the human factor**: Some vulnerabilities require social engineering or insider access. Factor in your threat model and the likelihood of these attack vectors for your organization.