Binarly Transparency Platform: A Next-Generation Approach to Reachability Analysis

Introduction

Modern software is built on complex supply chains of open-source and third-party components. According to industry data, a whopping 96% of applications contain open-source components, averaging 526 components per application, which leads to a deluge of vulnerability alerts.

Product security teams are often awash in vulnerability reports, where a large portion of findings turn out to be irrelevant or false positives. In fact, nearly one-third of teams report that most detected vulnerabilities are false positives. This overload creates alert fatigue and makes it difficult to identify which issues truly demand attention. Traditional scanning tools list every known CVE in every component without context, forcing teams to sift through hundreds or thousands of alerts, many of which pose no immediate threat.

Reachability analysis has emerged as a game-changer to cut through this noise with a specific focus on whether a vulnerable code path can actually be accessed (or “reached”) in a real-world scenario. Instead of treating all vulnerabilities as equal, it distinguishes those that are actively exploitable in the context of an application from those that are merely theoretical.

A vulnerability in a component that the application never calls is a vastly lower risk than one sitting in the direct execution path of user inputs. By homing in on reachable, exploitable issues, organizations can prioritize fixes on the vulnerabilities that truly matter and de-prioritize or filter out the rest.

Reachability analysis offers a critical, contextual filter to separate theoretical vulnerabilities from those that are truly actionable. At Binarly, we’ve taken reachability analysis to the next level. Our flagship Binarly Transparency Platform integrates advanced static and dynamic techniques with deep binary analysis to deliver a comprehensive view of vulnerability exploitability, tailored for today’s complex environments.

Understanding Reachability Analysis

The Core Challenge

Computing the reachability of a vulnerable code segment is inherently challenging. In a purely static context, determining whether a program point can be executed isn’t simply a matter of “yes or no.” Instead, it requires an intricate analysis of control flow, data propagation, and environmental configuration. To address these challenges, Binarly has developed a taxonomy of reachability that classifies vulnerabilities by the pathways through which they may be exploited, providing nuanced insight into the actual risk posed.

Definitions and Taxonomy

Before delving into our approach, it is useful to clarify a few key definitions:

• Container: A collection of software components and artifacts.
• Component: A single piece of software (e.g., an executable, shared library, or firmware blob).
• Artefact: Any non-software file or blob within a container.
• Environment: The static or dynamic configuration that determines which components are loaded, their execution order, and how they interact.
• Entry-point: A location within a component where execution can begin (for instance, the main function in an executable or an exported function in a shared library).
  

Binarly’s analysis differentiates several types of reachability:

1. Direct Reachability: A straightforward path exists from the primary entry-point (e.g., the main function) to the vulnerable program location.
2. Exported Reachability: Indirect paths exist from an exported function – common in shared libraries or firmware modules – leading to a vulnerability.
3. Referenced Reachability: A vulnerability is flagged as reachable because it is referenced by code already reachable by the direct or exported paths, even if the exact path is indeterminate.
4. Undetermined Reachability: Cases where static analysis cannot conclusively determine if a vulnerable point is reachable.

These classifications help prioritize vulnerabilities not simply by their severity, but by how “reachable” they are in the context of the environment in which the software runs.

Binarly’s Approach to Reachability Analysis

At the core of our platform is an advanced static analysis engine that decomposes a software component into its basic building blocks. Here’s how we do it:

1. Control-Flow Graphs (ICFGs) - We construct inter-procedural control-flow graphs, where vertices represent basic blocks (sequences of machine instructions ending in control-flow changes) and edges represent branches, calls, or other control-flow altering instructions. Multiple graphs may be generated to capture dead code, library components, or unresolved indirect calls.
   
2. Data-Flow Analysis - Using abstract interpretation techniques (such as Value Set Analysis), we approximate the values held by program variables at different points in the code. This allows us to infer additional control-flow edges, remove impossible branches, and refine the overall reachability picture.
   
3. Code Cross-Reference Graphs - By mapping load operations and references between basic blocks, we overlay a secondary graph onto the ICFGs. This cross-reference graph captures transitive relationships—if block A loads a data structure that refers to block B, an edge is added from A to B—enhancing our ability to trace potential exploitation paths.
   
4. Entry-Point Identification -  We automatically identify viable entry-points based on the component type. Whether it’s the main function in an executable, exported functions in a shared library, or designated Interrupt Service Routines in firmware, our system systematically marks all points from which execution may begin.
   
5. Reachability Computation - With the ICFGs and cross-reference graphs in hand, we compute the reachability of vulnerable program points by checking for paths from any identified entry-point. In cases where a preliminary analysis suggests non-reachability, we perform a deeper symbolic execution of the paths for a reachability “proof.”
   
6. Trace Evidence and Metrics - For every vulnerable point identified as reachable, our platform produces trace evidence—a documented path through the call graph—and quantifies the complexity of that path using branching factors, distance metrics, and the number of distinct execution paths available. This detailed evidence underpins our risk classification.

Inter-Component and Environment-Aware Reachability

Software does not operate in a vacuum. Components interact, and the environment in which they run -- defined by configuration files, boot scripts, container entry-points, and more -- critically influences vulnerability exploitability. Binarly extends reachability analysis beyond the single component to include:

• Inter-Component Reachability - We construct inter-component call graphs that model how components interact through exported functions. If a component’s entry-point is invoked by another component, that interdependency increases the overall risk. This graph-based approach allows us to quantify risk on a broader, systemic level.
  
• Environment-Aware Reachability - By integrating information about how components are configured and loaded -- whether in a Docker container, an embedded Linux system, or a UEFI environment -- we refine our analysis. For example, the entry-point defined by a Docker container’s configuration or a boot-loader’s second-stage payload is factored into our reachability models. This environmental context can reweigh the impact of a vulnerability, providing a more accurate risk assessment tailored to the actual deployment.
  

Use Cases and Impact

Triage and Remediation Prioritization

By classifying vulnerabilities according to their reachability, the Binarly Transparency Platform transforms raw vulnerability data into actionable intelligence. Rather than treating every vulnerability equally, organizations can prioritize fixes for those vulnerabilities that are demonstrably reachable and hence pose a higher risk. This triage mechanism not only saves time but also focuses resources on mitigating the vulnerabilities that truly matter.

Risk Assessment for Third-Party Components

When evaluating third-party software or firmware, the sheer volume of reported vulnerabilities can be daunting. With our reachability metrics, organizations can assess the actual risk added by integrating a component. A component with a high number of reported vulnerabilities might, upon analysis, reveal that only a few are reachable in the target environment. This nuanced view empowers procurement and product security teams to make informed decisions without overestimating risk based solely on vulnerability counts.

Call-Graph Reachability Metrics

Our forthcoming call-graph reachability metrics will further refine this approach. These metrics will report exactly how a vulnerability can be reached within a binary, classifying it based on:

• Direct (Entrypoint) Reachability: A clear, direct path from the binary’s main entry-point.

• Exported Reachability: Reachability through functions exported for external use.

• Referenced Reachability: Cases where reachability is inferred indirectly.

• Undetermined Reachability: Where static analysis cannot conclusively determine reachability.

Early examples in domains such as Baseboard Management Controller (BMC) firmware and UEFI modules have already demonstrated how these classifications correlate with real-world exploit scenarios.

Conclusion

In a world where vulnerabilities are reported in overwhelming numbers, reachability analysis offers a critical filter—focusing remediation efforts on those vulnerabilities that truly pose a risk. The Binarly Transparency Platform harnesses advanced control-flow and data-flow analysis, symbolic execution, and environmental context to provide a comprehensive, multi-layered view of vulnerability exploitability.

By classifying vulnerabilities into direct, exported, referenced, and undetermined reachability categories -- and by producing trace evidence and quantitative metrics -- the platform enables enterprise procurement and product security teams to:

• Reduce alert fatigue: By focusing on actionable vulnerabilities.
• Optimize remediation efforts: By prioritizing based on realistic risk.
• Empower procurement and product security: With detailed, context-aware risk assessments that enhance supplier negotiations and informed decision-making.

Binarly’s approach represents the cutting edge of vulnerability management—bridging the gap between deep technical analysis and strategic risk management, and ensuring that every vulnerability is understood not just as a number on a report, but as a real-world risk that can be measured, prioritized, and ultimately mitigated.