> ## Documentation Index
> Fetch the complete documentation index at: https://docs.binarly.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Attack Surface Approximation and Prioritisation (ASAP)
> How Binarly computes reachability across four levels, from within a single binary up to the environment-aware attack surface, to prioritise the findings that actually matter.
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.
Reachability is a filter that preserves relevant findings. It reduces finding fatigue by scoping thousands of raw results down to the ones exposed to the assumed attack surface, without discarding data through naive allow/deny filtering.
## Definitions
| Term | Meaning |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Container** | A collection of software components and artifacts. |
| **Component** | A single piece of software: an executable, shared library, or firmware blob. |
| **Artifact** | A non-software file or blob inside a container. |
| **Environment** | A configuration of components and artifacts that determines which components load, which runs first, and how components interact with each other, with artifacts, and with the outside world. It may include a component loader and mechanisms for restricting interactions. |
| **Entry-point** | A location within a component where execution can start, such as an executable's `main` function or a shared library's exported function. It may or may not be advertised to other components or the program loader. |
## The reachability hierarchy
Binarly answers three progressively broader questions about a finding, then combines the answers in ASAP:
Is this vulnerable location reachable from a well-known entry-point of the binary it lives in?
Is this vulnerable library function actually called by another component?
Is this vulnerable component actually executed or loaded under the package's assumed configuration?
Combine the levels above to approximate the relevant attack surface: any component and code that runs or loads and is reachable with respect to the assumed runtime environment and inter-component reachability.
## 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:
| Class | Meaning |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Entrypoint** | A path exists from the component's original entry-point (such as `main` or `start`) to the vulnerable location. |
| **Exported** | Indirect reachability from a viable exported entry-point. For shared libraries this means exported functions; for UEFI it covers identified SMI handlers and functions in registered protocol interfaces and PPIs. |
| **Referenced** | The location is referenced by code that is reachable from an entrypoint or exported function, but exact reachability cannot be determined statically. |
| **Undetermined** | Reachability cannot be determined statically. |
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](/user-guides/image-scans/reachability-filtering).
Improving reachability accuracy is an ongoing research effort in the Binarly research team. Intra-component reachability is reported for platforms where Binarly performs in-depth code analysis.
## 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.
On real containers and images, scoping findings to the ASAP attack surface reduces the count of findings to assess by roughly an order of magnitude, depending on container or image size. The same computation supports a fast-scan configuration: analyse in depth only the components assumed to be reachable.
### 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:
| Environment | Meaning |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Container** | A container image, such as a Docker container. |
| **System image** | A disk image of an OS installation. |
| **System firmware** | A firmware image, such as a UEFI firmware image. |
| **Undetermined** | The environment could not be determined precisely, for example a BMC firmware image that resembles a generic Linux image. |
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:
| Kind | Meaning |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Entrypoint** | Reachable from the advertised environment entry-point, such as a container's entrypoint. |
| **Runtime Invocation** | Reachable because another component may invoke it at runtime. The referent identifies the invoking component. |
| **Runtime Dependency** | Reachable because another component may load it as a dependency, for example through dynamic linking. The referent identifies the depending component. |
| **Undetermined** | Reachability could not be determined, or the component is outside the assumed attack surface. |
## 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](/resource-center/ems-escalations) 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](/user-guides/image-scans/all-about-details), 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](/user-guides/image-scans/reachability-filtering).
* Reachability feeds the [Binarly Risk Score](/resource-center/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](/user-guides/export/vex), [CBOM](/user-guides/export/cbom), and [PQC reports](/user-guides/export/pqc).
## Reference
Reachability Analysis for Binary Executables. Matrosov, Thomas, Vasilenko. US Patent 12,287,885 B1, April 2025.
## Related
How reachability reweights a finding's risk score.
Real-world exploitation evidence that complements reachability.
The classes of finding reachability is computed for.
How Binarly reports confidence in its results.