Attack-path graph

For every detected entry point (API route, CLI handler, MQ consumer, cron job), Vulkro walks the call graph forward and emits one attack path per (entry, reachable critical sink) pair in at most N hops (default 8).

Each path carries:

• The entry point's HTTP method + path (or handler name).
• The sink category and the call shape (e.g. stripe.charges.create).
• An ordered list of (file, function, line) hops from entry to sink.
• The set of hops that lack any recognized auth marker in the function name (require_auth, tenant_*, session_*, ...). The desktop console renders these in red so the reviewer can answer "where does the kill chain skip authorization?".

When to use it

• Incident response. "We saw a suspicious payment. Which routes can reach stripe.charges.create?"
• Auth review. Sort the report by gates_missing_hops. Any path whose middle hop has no auth marker is a candidate for a pre-commit gate.
• Onboarding. Hand the report to a new engineer. Each path is a guided tour of how requests fan through the codebase.

Rendering

The desktop console hosts an Attack paths tab in the project's Security group. CLI output: vulkro scan --format attack-paths for JSON, vulkro scan --format attack-paths-md for the markdown digest.

Pairs with

• Reverse-reach for the inverse: given a finding, which entry points reach it?
• Bruteforce sinks to see which payload classes can travel each attack path.