Attack Surface Approximation and Prioritisation (ASAP)

Whether the flaw can be reached is a reasonable proxy for how easily it can be exploited, or whether it is exploitable at all. In a static setting, reachability is neither simple to compute nor well captured by a single yes/no answer. Binarly models it across four levels, from a single function inside one binary up to the components that actually execute in a deployed package. Attack Surface Approximation and Prioritisation (ASAP) is the top level: it approximates the attack surface of a package and scopes findings to the code that runs. Used this way, reachability complements existing severity and exploitability metrics such as CVSS, EPSS, and SSVC. Those metrics rate a vulnerability in the abstract. Reachability asks whether the vulnerable code is reachable in this artifact and under this deployment.

​

Definitions

​

The reachability hierarchy

Binarly answers three progressively broader questions about a finding, then combines the answers in ASAP:

​

Intra-component reachability

A component does not run all at once. A vulnerability sits at some location in its code, and that location is only a concern if execution can actually reach it. Binarly statically analyses each component to determine whether a vulnerable location is reachable from an entry-point, resolving indirect control flow where it can and reporting conservatively where it cannot. Entry-points depend on the component and platform:

• A shared library’s exported functions.
• An executable’s start or main function.
• For UEFI, a driver or module’s protocol interfaces, PPIs, registered event handlers, and identified SMI handlers.
• For firmware with an Interrupt Vector Table, the defined Interrupt Service Routines.

Each reachable location is classified by the kind of entry-point it is reachable from.

​

Classifying reachability

Reported from high to low risk: Alongside the class, Binarly provides trace evidence: one or more paths showing that the location is reachable, and a measure of how hard it is to reach. In the platform, these classes appear in the Code Reachability column. Findings with no analysable code show N/A. See Filtering findings by reachability.

​

Inter-component reachability

A component does not run in isolation. Binarly determines how components call each other’s exported functions, so an exported function counts as a viable entry-point when another component calls it. This shows how a vulnerable component affects the components that depend on it: if ApplicationX links to LibraryY and calls vuln_fcn1, and LibraryY links to LibraryZ and calls vuln_fcn2, then ApplicationX is affected by {vuln_fcn1, vuln_fcn2}. Libraries loaded at runtime are included where that use can be identified statically.

​

Environment-aware reachability

An execution environment holds both software components and artifacts. Artifacts may be regular files, but some configure the runtime. In an embedded Linux environment, boot scripts determine which components load and run during initialisation. That list, together with later component-specific configuration files, determines the set of components that can run. Binarly may not determine this set exactly, but it approximates it and uses the result to mark which component entry-points are viable. Binarly approximates which components run from the package configuration:

• Containers, from the OCI image configuration: the Entrypoint, Cmd, and Env properties determine what launches when the container starts.
• Linux-like firmware and system images, from standard start-up scripts such as those under /etc/init.d/.
• System firmware, from the firmware image structure, for example the modules present in a UEFI firmware image.

From these seeds, Binarly discovers which components execute and what they depend on, then propagates that information to downstream analyses so each finding carries its reachability context.

​

ASAP: approximating the attack surface

ASAP combines the levels above into a single question: given the components that will run or load, and how they reach each other, which findings sit on the relevant attack surface? Everything else can be filtered out or de-prioritised. The relevant attack surface is any component and code that runs or loads and is reachable with respect to the assumed runtime environment and inter-component reachability.

​

How ASAP discovers reachable components

ASAP determines which components are likely to execute under a given configuration. Each supported package type has a default policy for which components are assumed to execute first. From there, ASAP follows each component’s runtime dependencies and the components it invokes, adds the newly discovered components, and repeats until no new components are found.

​

The environment reachability metric

For each component that may execute under ASAP’s assumptions, the reachability is attached to every finding on that component. Each result records the environment it was derived from, the reachability kind, and a confidence value. The environment classes are: A component reachable from more than one other component carries more than one result, each naming the referent component it is reachable from. Components outside the assumed attack surface are reported as undetermined. In the findings grid and finding detail these appear as the Environment Reachability values and their from Component(s) list. The reachability kinds are:

​

Where reachability is used

Reachability is a reweighting factor for existing severity and exploitability metrics. Binarly applies it to:

• Triage prioritisation: the order in which vulnerabilities should be assessed, highest risk first.
• Remediation prioritisation: the order in which vulnerabilities should be patched.
• Third-party component risk: how much additional risk a component with a known vulnerability introduces in the context of a larger product, given its reachability profile.
• Risk reweighting: when reachability is computed at the environment or inter-component level, it can rescore the impact or severity of a known vulnerability considered in the context of where it exists within a wider product.

Reachability answers whether a vulnerability can be triggered in your deployment. The Exploitation Maturity Score adds whether it is being exploited in the wild, so the two together drive remediation priority.

​

Reachability in the platform

Reachability appears throughout the Binarly Transparency Platform:

• On the finding details page, the Code Reachability and Environment Reachability results sit alongside CVSS, EPSS, EMS, and confidence to indicate exploitability.
• In the Findings grid, the Code Reachability and Environment Reachability columns each have a filter, so you can scope a view to reachable findings and combine the two. See Filtering findings by reachability.
• Reachability feeds the Binarly Risk Score: the reachability kind and confidence, for both code and environment reachability, reweight a finding’s score, so reachable findings rank higher.
• Reachability data is included in exports: VEX, CBOM, and PQC reports.

​

Reference

Reachability Analysis for Binary Executables. Matrosov, Thomas, Vasilenko. US Patent 12,287,885 B1, April 2025.

​

Related