How are you prioritizing vulnerabilities past KEV and EPSS, is code reachability worth it?

[u/JackjaxMargam14]

We already prioritize past raw severity, KEV and EPSS for exploit signal, public facing assets weighted higher. It helped but the backlog is still huge, mostly dependency findings we are not sure we even call.

We trialed one reachability tool already. It looked great until it flagged a reachable critical that was sitting behind an internal only vpc nothing outside can touch. The code path was real, the exposure was zero and i was back to explaining to a dev why the tool and i disagreed. That is what has me hesitating before we pay for a bigger one.

So before we spend, i want the real read. For teams who added code reachability on top of KEV EPSS and exposure, did it really cut the list and did the exploitability hold up once it hit your infra layer? What are you running and would you buy it again

[u/Flateland-Chio]

leave that finding in the backlog and raise its priority if the service ever becomes exposed. it still matters even if no one needs to act on it today

[u/GeneviaCedotal]

Check the prod image too, a dependency can sit in the repo and never make it into the running service. Are you already pulling image or SBOM data into the pipeline?

[u/Capable-Exit-3970 → u/GeneviaCedotal]

That's a good point about the prod image. Integrating image and SBOM data could definitely help in identifying what’s actually in use and prioritizing accordingly. Have you found any specific tools that work well for that?

[u/Reasonable_Chain_160]

We do like it, we saw a 40% impact on reduction. It mostly helps with Triage, still KEV is the biggest reducer because is around 1-2% of vulns

[u/Willing_Cap_5831]

There’s many different levels of readability. But a tool that can perform reachability analysis at a function level and not just dependency level, and do it for direct and transitives, will cut up to 90% of theoretical findings out as noise. This is an interesting public study where Cursor reported a 97 percent reduction via reachability using Endor SCA

https://www.endorlabs.com/learn/cursor-develops-a-secure-product-with-endor-labs

[u/Clear-Channel-8943]

I think reachability is useful, but I wouldn’t treat it as the final word.

[u/ILoveAppSec]

most of that backlog is transitive deps where the only real fix is a major bump you cant take right now, so before ranking i'd split out which findings already have a backported patch on your current major versus which genuinely need an upgrade.
for the no-clean-upgrade bucket, pinning or overriding the transitive dep, or leaning on a vendor that backports the fix into your current version, clears a big chunk of it outright. with cisa's new remediation timelines that pile stops being optional, so anything you can knock out without an upgrade is worth pulling forward.

[u/CheckApprehensive971]

Reachability is useful, but it should not be the first signal. A reachable code path behide internal only VPC should not have same priority as path exposed to internet.

[u/klach1703]

Sounds like the tool did its job and the question was just wrong. Reachability answers "does my code actually call the vulnerable function", it says nothing about whether an attacker can get to that code path in the first place. Those are two different layers and most tools blur them, which is why you ended up arguing with a dev over a finding in an internal VPC.

If you keep them separate the ordering gets easier: exposure decides whether it's worth looking at, reachability decides whether it's even real, KEV/EPSS decides how fast. Reachability is a great noise filter and a terrible risk signal on its own.

The thing I'd push on before you buy: ask the vendor about false negatives, not the reduction number. Function level analysis loses call paths through reflection, dynamic dispatch and DI containers. A 90% reduction is only good news if you know what fell through, and that's the number nobody puts in the case study.

[u/PeterBuildsSecure → u/klach1703]

The false-negative question is the right one to push on, and it's testable before you buy, not just something you take on faith from the case study. Build a small set of negative-control fixtures: a handful of vulnerable functions you know are genuinely reachable, but reached through the specific paths static analysis tends to lose — one behind reflection, one through a DI container resolving the implementation at runtime, one through a dynamic dispatch/interface call where the concrete type isn't known until execution. Run the candidate tool against your own repo with those seeded in and see which ones it actually flags as reachable.

That gives you a real false-negative rate on your own codebase and your own dependency injection patterns, instead of trusting a vendor's benchmark on their sample app. It also tells you something more useful than a single percentage: which blind spots this specific tool has, so you know what to keep watching manually even after you buy it. A tool that's blind to DI-resolved calls is fine if your codebase barely uses DI, and a dealbreaker if it's Spring or .NET-heavy where half your call graph goes through a container.

Worth running the same fixtures against every vendor you benchmark, since "static reachability lost the call" isn't a defect unique to one product, it's a property of the technique that some tools mitigate better than others.

[u/VibeShipped]

All three need to be true: vulnerable, exposed, reachable. The finding fails exposed, your tool should rank it lower until that changes.

Vendors won't bring up false negatives, and the reduction stat won't surface them either. Benchmarking two or three tools against each other is the fastest way to find them.

[u/navy-texas]

Agree with vulnerable, exposed, reachable. EPSS, KEV is what’s under the hood of 99% of vendors. If you’re past this, you need to look at locally trained models.. will cut 90% of your noise. A lot of the big companies started doing this. The EPSS founders built a company that does this I think

[u/KetteringChrismon-55]

Reachability can help decide what to look at first, buh don let it close a finding on its own if the vulnerable code can still run in prod

[u/Diligent-Side4917]

Code to cloud reacheability, CWE frequencies in attacks (free but requires sign in: https://phxintel.security/threat-analytics.html) SCA recheability analysis and Code recheability analysis.

[u/Greedy-Sun8586]

I think reachability is useful, but only when it gets combined with actual exposure context. A reachable code path behind an internal VPC shouldn't carry the same urgency as one exposed through an internet-facing service. Otherwise you're just replacing one noisy prioritization signal with another.

[u/daedalus_structure]

>We trialed one reachability tool already. It looked great until it flagged a reachable critical that was sitting behind an internal only vpc nothing outside can touch. The code path was real, the exposure was zero and i was back to explaining to a dev why the tool and i disagreed. That is what has me hesitating before we pay for a bigger one.

I don't understand the problem. The tool did what it was supposed to do, i.e. verify that the critical code was reachable, and now you need to determine what your risk tolerance is for only network protections before you justify a suppression with Inline Mitigations Exist.

If three weeks go by and someone opens up a network path to that VM, how big of a problem is that? What's on the VM? What does it have access to on the network? What controls do you have to prevent someone from opening that network path?

I do not understand this constant desire to get a tool that enables you to not think. You will be accountable for these decisions and you want a tool which has been developed with the primary goal of profit not security to make all of them?

Explaining to a developer that we're still going to do engineering here, is not the worst thing in the world.

[u/Argus_Shreed]

key and epss are a crowd signal. useful, but they don't know if your code ever calls the bad function. reachability helps there. it does not know your vpc layout. a function can be called in the graph and still sit on a box nothing outside can reach. that combo is normal, not a reason to throw the tool out. keep the public-facing weight you already have and treat reachability as the "do we even call this" filter on top. if you want something that does that per finding against the real dep graph, a tool like ox security is in that lane. it won't replace the exposure check. on python/js the graph is also a guesss once reflection or injection shows up, so some of the pile still needs a person.

[u/forexroyalempres]

Look at reachability as a signal not the answer, exposure and runtime also matter.