Everything You Ever Needed to Know About Reachability (But Were Afraid to Ask)
Stop chasing ghosts and unlock true security with SCA reachability.
To understand reachability, we need to take a step back and think about Software Composition Analysis (SCA) more broadly. At its core, SCA is all about scanning software projects to identify their dependencies, and then linking these dependencies to known vulnerabilities — typically captured in CVEs (Common Vulnerabilities and Exposures).
An effective SCA tool alerts you whenever you're using a dependency with a known vulnerability, so that you can resolve these issues, usually by upgrading to a new version. Without SCA highlighting these vulnerabilities in your software projects, attackers can use the list of publicly disclosed CVEs as a convenient roadmap to identify and exploit vulnerabilities in software dependencies. Addressing these vulnerabilities quickly using SCA reduces your exposure and potential risk. But where does reachability come in?
Who is Inside Your Home? Understanding Transitive Dependencies
One surprising aspect of SCA, especially for newcomers, is realizing how many vulnerabilities lurk not just in your direct dependencies but deep within your transitive dependencies, which are indirect dependencies your software relies on. For example, you might actively use and trust the popular JavaScript framework Vue, but you might be unaware of the dozens of smaller dependencies Vue itself depends on. When developers first encounter CVEs in these transitive dependencies, a common reaction is confusion: "I'm not even using that dependency!" The truth, however, is nuanced. If a dependency exists anywhere in your project's dependency tree (or graph), you're technically "using" it — even if not directly. It’s like inviting two close friends to a party in your home, people you know well and trust implicitly. If they each bring along an unknown plus-one who behaves badly, it’s still your space that’s impacted, and ultimately — it’s your glass vase that gets broken.
But what if their obnoxious plus-one never shows up to the party? In that case, it doesn’t practically matter if your friends have a connection to a dangerous person. This is where the concept of "reachability" becomes crucial. While a dependency may exist in your dependency tree, you might never invoke its vulnerable functions or features. Even more subtly, perhaps you're only using a limited set of capabilities within a given dependency in the first place. If the known vulnerability resides in a portion of the code you're not using, addressing that issue could be unnecessary. Spending valuable development time resolving a vulnerability that isn't realistically reachable is, quite simply, wasted effort — like hiding all the Hershey’s from a chocoholic who hasn’t even RSVP’d.
Visualizing Where the Risk Truly Lies
This highlights the practical significance of reachability analysis, but how can we know if a vulnerability is reachable? Ideally, we would love to have complete visibility into every single function or file your application truly uses — but that level of detail quickly becomes overwhelming and impractical. And yet, no more than 20% of vulnerabilities are actually exploitable at the function level. If your SCA tool doesn't consider reachability, you could potentially be dedicating five times the effort needed to address vulnerabilities. Even if you strategically prioritize based on severity or potential impact, you'd still waste significant time addressing vulnerabilities that pose no real-world risk.
At this point, it's clear that combining SCA with effective reachability analysis translates directly into efficiency and cost savings. However, it's important to recognize that not all reachability analysis deliver the same value. Broadly speaking, there are two approaches: dynamic/runtime reachability analysis and static reachability analysis.
Dynamic/Runtime Reachability Analysis
Dynamic or runtime reachability analysis tracks code execution in real-time production environments, helping you understand which lines of code (along with which vulnerabilities) have actually been executed. Sounds great, right? However, while valuable for prioritizing critical vulnerabilities and especially in understanding immediate threats, runtime analysis does not reduce your overall workload, and it doesn’t allow you to be proactive about risk.
Even if certain lines haven't been executed yet, you can't confidently dismiss vulnerabilities based on current runtime data alone. To illustrate, imagine your software runs a pizza-ordering app, and there's a vulnerability allowing users to bypass payment by entering a specific string (like "#########"). Runtime analysis can indicate whether anyone has already exploited this vulnerability, but it won't predict whether someone can exploit it in the future. While runtime analysis can help prioritize current risks, it doesn't save time by identifying reachable vulnerabilities or eliminating unreachable vulnerabilities upfront. To go back to our unwelcome party guest example, dynamic or runtime reachability could tell you if someone has thrown up in the pool, but it won’t take the beer out of their hands before they get in the front door.
Tightening the Guest List: Static Reachability Analysis
In contrast, static analysis assesses your source code directly, mapping out potentially reachable and unreachable code paths without requiring execution in a live environment. How does it work? Interestingly, static reachability solutions typically adopt one of two strategies:
The solution identifies all vulnerabilities that are definitely reachable, marking everything else as "potentially reachable."
The solution identifies vulnerabilities that are definitely unreachable, marking everything else as "potentially reachable."
These may sound similar, but in reality, only the second strategy genuinely saves time and effort. Knowing what is reachable doesn’t allow you to have confidence that all other vulnerabilities aren’t opening your software up to risk. They remain a potential threat. However, by explicitly identifying the vulnerabilities that are unreachable, static reachability analysis lets you confidently exclude the vast majority of identified vulnerabilities, focusing your team's limited resources on what’s left, which is the vulnerabilities that matter. In the context of our house party, by accessing a list of known and trusted guests, you can deal with anyone else at the door, and in the meantime, allow yourself to enjoy the music.
SCA Reachability with a Practical Perspective to Reduce Workload
Integrating SCA with static reachability analysis isn't just good practice — it's an essential strategy for saving valuable developer time, managing risk effectively, and maximizing your team's productivity.
Ready for some good news? Mend.io’s SCA Reachability solution was designed with these exact benefits in mind, and can streamline your development efforts and allow you to act proactively to reduce risk down to only reachable vulnerabilities. Our tool explicitly identifies your unreachable vulnerabilities, enabling you to significantly streamline your vulnerability management processes. Instead of getting bogged down in countless irrelevant alerts, you can concentrate on the vulnerabilities that pose genuine risks to your software — those uninvited guests who are eyeing up the silverware.
-Rhys Arkins, VP Product Management at Mend.io