Attack-path graph

For every detected entry point (API route, CLI handler, MQ consumer, cron job), Vulkro walks the call graph forward. It emits one attack path per (entry, reachable critical sink) pair within 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 hops whose function name carries no recognized auth marker (require_auth, tenant_*, session_*, ...). The desktop console shows these in red, so a reviewer can see where the chain skips 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 has an Attack paths tab in the project's Security group. Each path's Reaches column names the kind of flaw at the end of the path (for example SQL injection or path traversal), taken from the finding's rule and CWE, or the OWASP API category when no more specific name applies.

Vulkro Cloud shows the same attack paths, with the same Reaches wording, for every connected code repository (Team plan and up). For CLI output, vulkro scan --format attack-paths gives JSON and vulkro scan --format attack-paths-md gives 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.