Instead of guessing at race conditions, memory leaks, attack paths, I architected a local engine that runs 7 parallel detection threads to recursively map entire Call Graphs.
It traces Tainted Control Flow across file boundaries to prove Deterministic Reachability, to give the exact execution path from input to crash without the theoretical noise of standard linters.
Here is the architectural breakdown:
Recursive Taint Analysis: Instead of regex-matching for "bad patterns" (like eval()), Blood Hound builds a complete Call Graph of the application. It maps data from Sources (Inputs) to Sinks (execution) across file boundaries. It does not flag a vulnerability unless it can prove a connected path exists in runtime. Therefore filtering out theoretical noise plaguing syntax testers.
Local Parallelization: To handle the computational load of tracking state across 2M+ LOC without timing out, the system runs 7 detection engines in parallel locally. This allows for exhaustive recursion to validate dependency chains too deep for manual review, all done locally.
White Box Execution: This is not a DAST that pokes from the outside. It operates as a White Box analyst, linking runtime crashes directly to the exact source lines causing them.
The Goal: I didn't build this to replace engineers. I built it to handle the computational drudgery of dependency tracing. It clears the false positives so I can focus on complex exploit chains.
It runs via CLI (blood hound). Just install needed.
If you are an Engineer with a repo in prod, I’d love for you to stress-test the reachability logic against your messiest repo and compare it to your other testing tools
Here's some images from how it looks inside the IDE:
