Skip to main content

Overview

The Exploitability Validation package provides a rigorous multi-stage pipeline for validating that vulnerability findings from static analysis are not just theoretical issues, but real, reachable, and potentially exploitable vulnerabilities.

Purpose

Validate findings through stages:
  • Stage 0 (Inventory): Catalog code structure and entry points
  • Stage A (One-Shot): Quick exploitability assessment
  • Stage B (Process): Attack path validation
  • Stage C (Sanity): False positive elimination
  • Stage D (Ruling): Hypothesis validation
  • Stage E (Feasibility): Binary exploit feasibility (memory corruption only)

Architecture

Quick Start

Full Validation Pipeline

With Pre-Existing Findings

Build Inventory Only (Stage 0)

Python API

ValidationOrchestrator

Main pipeline orchestrator.

Stage Execution

Agentic Validation (Stage A)

Core Classes

ValidationOrchestrator

Orchestrates multi-stage validation.

PipelineConfig

Pipeline configuration.
str
required
Path to code repository
str
required
Working directory for outputs
Optional[str]
Vulnerability type to validate (e.g., “sql_injection”)
Optional[str]
Binary path (required for Stage E)
Optional[str]
Pre-existing SARIF findings file
bool
default:"False"
Skip Stage E (exploit feasibility)
int
default:"3"
Max retry attempts per stage
bool
default:"True"
Enable JSON schema validation

PipelineState

Current pipeline state.
Optional[Stage]
Currently executing stage
Dict[Stage, StageResult]
Results for completed stages
Optional[Dict]
Code inventory (Stage 0)
Optional[Dict]
Validated findings
Optional[Dict]
Attack tree structure (Stage B)
Optional[List]
Validated attack paths (Stage B)

Pipeline Stages

Stage 0: Inventory

Catalog code structure.
Output: checklist.json

Stage A: One-Shot

Quick LLM-powered exploitability assessment.
Output: findings.json with status annotations

Stage B: Process

Validate attack paths through code.
Output: attack-tree.json, attack-paths.json

Stage C: Sanity

Eliminate false positives.
Output: Updated findings.json with sanity checks

Stage D: Ruling

Validate hypotheses with evidence.
Output: hypotheses.json, disproven.json

Stage E: Feasibility

Binary exploit feasibility (memory corruption only).
Output: feasibility.json

Validation Workflow

Complete Validation

Schema Validation

Validate Outputs

Create Empty Structures

Vulnerability Types

Supported Types

Memory Corruption Types

Configuration

Stage-Specific Config

Environment Variables

Output Structure

Integration

With Static Analysis

With LLM Analysis

Performance

Pipeline Duration

  • Stage 0 (Inventory): 5-30 seconds
  • Stage A (One-Shot): 1-3 minutes
  • Stage B (Process): 2-5 minutes
  • Stage C (Sanity): 30-60 seconds
  • Stage D (Ruling): 1-2 minutes
  • Stage E (Feasibility): 10-30 seconds
Total: 5-12 minutes per vulnerability type

Best Practices

  1. Start with Stage A for quick triage
  2. Use pre-existing findings to skip scanning
  3. Enable schema validation to catch errors early
  4. Review validation report for human verification
  5. Run Stage E only for memory corruption vulnerabilities