Reachability analysis

Security scanners optimise for count, which is exactly why nobody reads them. Point one at a project and it hands back hundreds of CVEs, ranked by a severity score that carefully ignores the only question that matters: can anything actually reach the vulnerable code? Most of that list is theatre. Real vulnerabilities, in real dependencies, on paths your program will never execute.

I've got some sympathy for the people drowning in these reports. I've spent years inside large, old codebases where the backlog was less a list of problems than a monument to alarms nobody could afford to investigate. A tool that told you which alarms were real would've been worth a great deal.

So this one answers the reachability question. Given a project and its CVE list, it builds an interprocedural call graph from the program's real entry points and works out which vulnerable functions are genuinely reachable. The shape of the answer is "212 CVEs, nine reachable", and each of the nine turns up with the path that proves it, so you can click from an entry point down to the vulnerable call.

The hard part

Static analysis gets lied to constantly. Dynamic dispatch, reflection, callbacks, plugin systems and cross-language boundaries all hide edges the call graph needs. Resolve them too loosely and everything looks reachable. Resolve them too tightly and you start dropping real paths, which, in a security tool, is the dangerous way to be wrong.

A VULNERABILITY YOU CAN'T REACH IS A CHANGELOG ENTRY, NOT A RISK.

So the design leans hard on being honest about uncertainty. A path's either shown with the evidence behind it or flagged as unproven, never quietly dropped. And the measure of success isn't really the size of the cut:

• a backlog of hundreds falling to single digits is the headline that gets attention;
• but the reachable few, each with a clickable path, are the ones that actually get fixed.

It's in design. The near-term work is language coverage and modelling the framework indirections that hide the hardest edges. A callback dispatched through a container is exactly the case that separates a useful answer from a confident but wrong one.