Reverse symbolic execution

Give Vulkro any finding's file and line. It walks the call graph backward and returns every entry point that reaches it. This helps when you triage "is this real?": the answer is usually "yes, if the sink is reachable from a route handler".

Output shape

For one target (file, line):

{
  "target_file": "services/db.py",
  "target_line": 42,
  "paths": [
    {
      "origin": "endpoint_e7",
      "origin_label": "POST /api/charge",
      "hops": [
        { "file": "routes/charge.py", "function": "handle_charge", "line": 11 },
        { "file": "services/billing.py", "function": "submit", "line": 25 },
        { "file": "services/db.py", "function": "execute_q", "line": 40 }
      ]
    }
  ],
  "unreachable_targets": [],
  "truncated": false
}

When paths is empty and unreachable_targets is populated, the finding sits in code that no entry point reaches through the resolved call graph. That means dead code, or code reachable only through dynamic dispatch the builder did not follow.

Bounds

• max_depth = 10 hops (Most real chains are < 8).
• max_paths = 64 per target (truncate flag fires when exceeded).

Adjust with VULKRO_REVERSE_REACH_DEPTH / VULKRO_REVERSE_REACH_PATHS.

Desktop console

Each finding card has a Trace back button. Click it to render the reverse-reach report inline. It deep-links into the local analysis API, so the whole round trip stays offline.

Pairs with

• Attack-path graph for the inverse direction.
• Bruteforce sinks to know which payload caused the finding.
• vulkro why <file>:<line> CLI subcommand (planned).