Filtering findings by reachability

The Findings grid reports reachability in two columns: Code Reachability and Environment Reachability. Read together, they tell you whether a vulnerable component’s code is actually executed in the deployed package. Code Reachability answers whether the vulnerable code is reachable inside its own binary. Environment Reachability answers whether that component runs or loads in the assumed runtime environment. Both come from Attack Surface Approximation and Prioritisation (ASAP), and each column has its own filter.

​

Prerequisites

• A completed image scan with findings.
• Access to the Findings grid for the image or product.

​

The two reachability columns

Each column answers a different question. Environment Reachability asks whether the component runs at all in the package. Code Reachability asks whether, once it runs, execution can reach the vulnerable code. Neither answer alone confirms that the vulnerable code runs; the combination does.

​

Code Reachability

Whether the vulnerable code is reachable from an entry-point inside the component that contains it.

​

Environment Reachability

Whether the component runs or loads in the package’s assumed runtime environment.

​

How reachability differs by ecosystem

The same column value is derived differently depending on the package. Code Reachability depends on what counts as an entry-point inside a binary, and Environment Reachability depends on how the package declares what runs. The Ecosystem column is the kind of package you uploaded; the Environment class is the label ASAP assigns once it identifies that package. Use this table to read the columns in the right context. See Reachability analysis (ASAP) for the full model. Reading this in practice, take each column in turn:

• Code Reachability reads the same on containers and Linux images, because both hold ELF binaries: main or start gives Entrypoint, and shared-library exports give Exported. UEFI has no main-style entry, so its reachable code is almost always Exported, entered through protocol interfaces, PPIs, registered event handlers, and SMI handlers.
• Environment Reachability starts from how each package declares what runs: containers from the OCI config, Linux images from start-up scripts, UEFI from the modules in the firmware image. Across all three, a component that runs shows Entrypoint, one component invoking another shows Runtime Invocation, and a loaded but possibly unused dependency shows Runtime Dependency. Runtime Dependency comes from dynamic linking, so it appears on containers and Linux, and rarely on UEFI, where modules interact through protocols and PPIs and show Runtime Invocation instead.

​

Reading the two columns together

Environment Reachability places the component on the attack surface. Code Reachability confirms the vulnerable path inside it. A finding is most likely to be executed when both signals are strong. This pairing holds for every ecosystem, but which values you actually see depends on it: on UEFI, the strong Code Reachability signal is Exported rather than Entrypoint, as covered in How reachability differs by ecosystem. Read the pair against this table:

​

Filter the grid by reachability

Each column has its own filter in the grid header.

​

Example: reachable, open known vulnerabilities

Build a triage view for known vulnerabilities that are most likely executed and still open:

• Type is Known Vulnerability.
• Environment Reachability is Entrypoint or Runtime Invocation.
• Code Reachability is Entrypoint or Exported.
• Status is New or In Progress, with Ignored off.

Sort by Risk Score, highest first. Reachability already feeds risk scoring, so reachable findings sort toward the top. To widen the net for a second pass, add Runtime Dependency and Referenced, then work down from there.

​

On the finding detail

Open a finding to see both signals in full.

• Code Reachability shows the Status and links to the reachability trace evidence.
• Environment Reachability shows the Environment it was derived from, the Reachability kind, and the components the reachability comes from under from Component(s), each with its path.

When a component is reachable from more than one other component, the Environment Reachability cell shows a count, such as 2 ER, and the detail lists each source under from Component(s). Check each component listed there to see whether it calls the vulnerable function. Each property changes how much weight the reachability carries:

​

Save and share the view

Once the filters and sorting are set, keep the view for reuse:

• Save the filter, sort, and column settings as a Saved View. Saved Views are scoped to the grid category (Global, Product Image, and so on).
• Copy the page URL to hand a teammate the same view. The grid encodes filters, sorting, and page state in the URL.

​

Related