Full Application Function-level Reachability

🚧

This feature is shipping in Q3. Stay tuned.

📘

See Reachability Analysis for an overview of all Reachability Analysis capabilities in Socket. This page is about just one of the reachability techniques that Socket offers.

The Dependency Function-level reachability allows Socket to remove 60% of vulnerabilities by looking at how packages in your dependency graph call into other packages in your dependency graph.

Full application reachability uses the same underlying reachability analysis engine, but it scans both the application source code and the dependency code. This allows the full application reachability to flag around 80% of vulnerabilities as irrelevant. For some ecosystems, the noise reduction rate is above 90%.

The benefits of full application reachability analysis include:

• Excellent noise reduction – Up to 90% of all vulnerability alerts can be flagged as irrelevant.
• Powerful triaging support – Provides a precise list of function calls from your application source code that lead to reachable vulnerabilities, making it easier to assess impact and severity.
• On-premise analysis – While the analysis reads your application’s source code, it runs entirely on-premise (on your machine) and does not share any source code with Socket.
• Phantom dependency detection – phantom dependencies are automatically detected and considered in the reachability analysis.

There are a few caveats to using the full application reachability analysis. It requires a small amount of manual configuration per repository and can be compute-intensive, depending on the programming language(s) and the size of the application.

Based on your organization’s security needs, you may choose to enable full application analysis for select repositories, while using dependency-level analysis for others.

How Full Application Function-level Reachability Works

1. Invoking the scan

The analysis is started using the Socket CLI or the Socket Reachability GitHub Action (available in Q3). The scan may be configured to run on regular intervals in your CI system or triggered by other events depending on policy.

2. Scanning for CVEs

The analysis identifies all manifest files (package.json, go.mod, Gemfile, pom.xml, build.gradle, and others) in your application. From these files, a complete list of direct and transitive dependencies — along with the dependency graph that connects them — is extracted.

Socket scans for CVEs in the dependency graph using a standard vulnerability scan.

3. Computing Vulnerability Reachability

For every detected CVE, a static analysis is performed to check the reachability of the affected function (You can learn more about Socket's static reachability analysis here).

This step involves constructing a model of your application called a call graph, which represents which functions call other functions throughout the application. Depending on the size and complexity of your codebase, this process may require significant memory and CPU resources, and can take up to a few minutes to complete for some CVEs.

4. Reachable vs Unreachable CVEs

If the affected function(s) are unreachable, the CVE is marked as unreachable. Unreachable CVEs are safe to ignore, as the vulnerable code cannot be invoked at runtime.

If the CVE is reachable through one or more paths, the vulnerability is flagged as reachable. For reachable CVEs, Socket shows the list of function calls in your dependencies that may trigger the vulnerability.

FAQ

How does Socket determine which functions are affected by a CVE?

You can learn more about how the Socket team identifies functions affected by vulnerabilities in the FAQ section of the Static Reachability Analysis page.

How does Full Application Function-level Reachability compare to Dependency Function-level Reachability

Dependency-level reachability analysis considers only the code within your dependencies, whereas the full application analysis also scans your application’s own source code. While the full application analysis provides better noise reduction and richer context for triaging reachable vulnerabilities, it comes with some trade-offs: it requires manual setup and is generally slower, as the static analysis is compute-intensive.