Static Reachability Analysis

An important advantage of Socket's SCA over other traditional vulnerability scanners is its reachability analysis that determines which vulnerabilities are actually reachable from the entry points of your project. This is important because in most projects, the majority of vulnerabilities (typically more than 80%) are not reachable and thus not exploitable.

The full application and precomputed reachability analyses are powered by advanced static analysis techniques that, depending on the analysis type, scan both your application’s source code and its dependencies. This enables the analysis to build a detailed model of how dependencies are used within your application.

Built on decades of cutting-edge research in static analysis, the tool is designed to handle complex language features effectively - including reflection in Java and dynamic reads and writes in JavaScript.

Socket’s reachability analysis can identify vulnerabilities not just in direct dependencies, but also in indirect (transitive) ones - including dependencies of dependencies, and so on, to any level of depth.

(Read more about Socket's approach to reachability analysis in this blog post).

The advantages of the static reachability analysis used by Socket are:

• Unlike other vendors, you don't have to install disruptive runtime agents in your production environment to conduct reachability analysis.
• In dependency reachability and precomputed reachability modes, the reachability analysis is available to all existing Socket users without any additional setup (dependency reachability on Free/Team/Business/Enterprise, precomputed reachability on Team/Business/Enterprise). In full application reachability mode, it runs via the Socket CLI that automatically gathers all the information needed to perform the analysis on your project, making it extremely easy to adopt.
• It uses tailored static analysis for each programming language, making it exceptionally accurate and capable of reasoning about the reachability of vulnerabilities deep down in dependency graphs.

Limitations

There are some limitations and caveats to the reachability analysis.

Accuracy

We are committed to building highly accurate reachability analyses. However, no analysis is ever perfect, and in very rare cases, vulnerabilities may be incorrectly reported as unreachable.

To minimize these inaccuracies, we design language-specific static analyses capable of handling complex language features—such as reflection in Java and dynamic reads and writes in JavaScript—effectively.

Additionally, our reachability analysis is intentionally conservative: a vulnerability will only be marked as unreachable if there is strong confidence that it truly cannot be exploited.

Performance

Reachability analysis is computationally more expensive than traditional vulnerability scanning, which may result in long-running scans for certain types of projects. This is only relevant for full application reachability.

Scope

Socket's static reachability analysis examines how your code interacts with its dependencies, and how the code of those dependencies interacts with their own dependencies, continuing recursively through the entire dependency graph.

However, the analysis is limited to interactions that occur within code and does not consider uses of dependencies that happen outside of code. For example, if you have a dependency on a build tool that you only invoke through its command-line interface, the reachability analysis will mark all vulnerabilities downstream from that CLI tool as unreachable—since there is no code-level interaction to trace.

When a vulnerability exists in a package that is primarily intended to be used as a CLI tool, we classify its reachability status as not determinable.

The analysis includes a best-effort mechanism to account for packages that are loaded through reflective mechanisms. For example, classes loaded via Java properties files are considered potentially reachable even though they are not directly referenced in application code.

.NET and Rust

Socket’s static reachability analysis for .NET and Rust used in the full application and precomputed reachability modes operates at the class level rather than the function level.

This approach is chosen because it works effectively across both source code and compiled artifacts (such as .NET bytecode). That flexibility is especially valuable in full application reachability mode, where it allows Socket to perform reachability analysis without requiring the application to be built, making both the analysis faster and the setup process significantly easier.

While class-level analysis isn’t true function-level analysis, it still achieves noise reduction rates comparable to function-level reachability in other ecosystems.

FAQ

How does Socket know which parts of a package are affected by a vulnerability?

For each vulnerability, Socket maintains a reachability specification: a description of which parts of the affected package (usually specific functions) are responsible for the vulnerability. The precomputed and full application reachability analyses use these specifications to decide whether your code, or your dependencies’ code, can actually reach the vulnerable parts of a package.

Every specification is produced by the same process:

1. Vulnerability disclosure: When a new vulnerability is reported, Socket’s reachability team is alerted.
2. In-depth investigation: The vulnerability is analyzed to understand how it impacts the package. This includes reviewing the vulnerability advisory description, studying the affected package’s documentation, inspecting the package’s code, and using internal AI tooling to extract as many insights as possible.
3. Reachability specification: A specification is created that clearly outlines which parts of the package, usually specific functions, are affected.

What differs between specifications is whether a human has confirmed their accuracy:

• AI-generated (also called auto-inferred): the specification has been generated and reviewed by Socket’s AI tooling, but a human reviewer has not yet confirmed it.
• Human-verified: a member of Socket’s reachability team has reviewed the specification and confirmed its accuracy.

A specification often starts out AI-generated and becomes human-verified once a reviewer gets to it, though not every AI-generated specification is eventually reviewed by a human.

By default, Socket reports reachability using only human-verified specifications. Organizations can opt in to also use AI-generated specifications for broader coverage, as described in the next section.

How do I opt in to AI-generated reachability specifications?

AI-generated specifications are controlled by an organization-level setting and are off by default. An organization admin can enable them in the Socket Dashboard under Settings → Alert Scans → Reachability, using the AI-reviewed reachability patterns toggle.

When enabled, Socket also reports reachability for vulnerabilities whose specifications are AI-generated (not yet confirmed by a human), in addition to those with human-verified specifications. This applies to both precomputed reachability and full application reachability. Enabling it increases how many vulnerabilities receive a reachability verdict, at the cost of a slightly higher risk of an incorrect result.

How can I tell whether a result used a human-verified or AI-generated specification?

When your organization has AI-reviewed reachability patterns enabled, the alert details for a reachable or unreachable vulnerability include a Specification field showing the provenance of the specification used for that result:

• Human-verified: a reviewer on Socket’s reachability team has confirmed the specification.
• AI-generated: the specification was generated and reviewed by AI but has not yet been confirmed by a human.

What happens if Socket's analysis doesn't yet have a specification for a vulnerability?

In that case the vulnerability is still included in the report, but it is marked with an unknown reachability status. We strive to add support for all new vulnerabilities within 24 hours of their public disclosure. If your organization has opted in to AI-reviewed reachability patterns, an AI-generated specification may already be available before a human has confirmed it, reducing the number of vulnerabilities left with an unknown status.

What if a vulnerability cannot be tied to a specific part of a package?

We use a fallback mechanism to handle cases where a vulnerability cannot be tied to a specific part of a package. This often includes vulnerabilities in packages used as Command Line Interface (CLI) tools rather than libraries. For these cases, we classify the reachability of the vulnerability as unknown and provide guidance on what you should manually check to determine whether your application is affected.

Many of these vulnerabilities are safe to ignore in most scenarios — for example, if the vulnerability is in a package typically used only during the application’s build phase, such as CVE-2023-45133. If your manual assessment concludes that a vulnerability is irrelevant to your context, we recommend using alert triage to ignore it.