Verification Workflow

Trace VScanX's end-to-end execution pipeline from lightweight fuzzing to sandboxed exploit validation and normalized report generation.

Mental Model

To achieve reproducibility-driven security tracking and reduce false positives, VScanX separates targets discovery from active exploit execution. If a scanning module discovers a potential redirect vulnerability on your target API, it never directly executes the validation attack on the main target host.

Instead, the framework coordinates an isolated validation sequence—spinning up sandboxed nodes, local EVM state forks, or gVisor workspaces to safely assert exploitability before compiling JSON findings.

The 5 Chronological Stages

Every scan lifecycle progresses through five distinct execution boundaries:

Stage 1: Passive Probing & Discovery

Lightweight modules (e.g. idor_detector.py or reentrancy_analyzer.py) scan baseline targets. They analyze query parameters, headers, transaction histories, or smart contract AST bytecode structures. No active exploit payloads are sent.

Stage 2: Event Broadcast (Typed Event Contracts)

If an anomaly is flagged, the module publishes a strongly-typed AnomalyEvent containing target metadata to the Event Bus (core/events/bus.py). The scanner module cleanly exits, freeing up thread pools.

Stage 3: Sandbox Provisioning & Orchestration

The central Orchestrator consumes the event. It automatically provisions an ephemeral, fully isolated sandbox environment tailored to the module domain (spawning a local Docker container or executing a local block-state EVM fork).

Stage 4: Exploit Payload Validation

The Verification Engine (core/verify/engine.py) triggers dynamic exploit checks inside the sandbox. It measures outcomes deterministically (e.g. verifying root command execution or contract balance mutation), proving exploitability safely.

Stage 5: Canonical Report Generation

Only verified findings are compiled to reports. The findings JSON lists exact validation traces and proof schemas, guaranteeing immediate, low-noise reproducibility records for developers.

Decoupled Event Contract Payload

VScanX defines strongly-typed schema models for event serialization (`core/events/schemas.py`). The following is a realistic `AnomalyEvent` payload contract:

{
  "event_id": "ev_981A402D",
  "timestamp": "2026-05-27T14:02:11Z",
  "type": "SSRF_ANOMALY_FOUND",
  "payload": {
    "target_url": "https://enterprise-target.io/login",
    "vulnerable_parameter": "next",
    "passive_heuristic": "redirect_query_detect"
  },
  "trace_id": "tr_00912BCX"
}

Realistic Verification Traces

When the Verification Engine audits a flagged event inside an EVM or Web sandbox, it writes structured telemetry traces. The following log snippet illustrates a successful, high-confidence metadata verification:

[22:02:15] [core.orchestrator] Received event: SSRF_ANOMALY_FOUND (trace_id: tr_00912BCX) [22:02:16] [core.orchestrator] Spawning isolated Docker validation container: vscanx/val-web:latest [22:02:16] [core.verify.engine] Executing active metadata payload assertions inside sandbox... [22:02:17] [core.verify.engine] payload dispatched: https://enterprise-target.io/login?next=http://169.254.169.254/latest/meta-data/ [22:02:18] [core.verify.engine] AWS metadata response captured: ami-id / iam/security-credentials [22:02:18] [core.verify.engine] [SUCCESS] Target vulnerable to Critical SSRF. Confidence: 1.0 (VERIFIED) [22:02:19] [core.reporter] Compiling canonical finding for trace: tr_00912BCX