Module Reachability
Module Reachability filters out unreachable CVEs so you can focus on vulnerabilities that actually matter to your application.
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 uses.
Modern applications are built on mountains of open‑source code. A single package.json or pom.xml can pull in hundreds—sometimes thousands—of transitive packages you’ve never heard of. Traditional security scanners treat every one of those packages the same, burying you in vulnerability alerts that may never be exploitable in your code base.
Module Reachability changes that. By understanding which transitive dependencies your application actually uses, we filter out the CVEs that can’t touch you—so you can focus on the ones that can.
The Problem: Noise Overload
If you’ve ever opened a security dashboard to find hundreds of “critical” issues, you know the feeling:
- Alert fatigue. When everything looks urgent, nothing feels urgent.
- Wasted cycles. Triaging false‑positive CVEs steals hours from real work.
- Slow remediation. Teams struggle to pick out the vulnerabilities that really matter to their runtime code.
We built Module Reachability to flip that script.
How Module Reachability Works
1. From Manifest to Map
We start where package managers start: your manifest files (package.json, go.mod, Gemfile, pom.xml, build.gradle, and more). That gives us a complete list of direct and transitive dependencies, plus the graph that connects them.
2. Smart Source‑Code Scan—No Peeking at Your IP
For each supported language we parse only the files we already store (never your proprietary source) and extract every import, require, or using statement:
| Language | Parser | Example we catch |
|---|---|---|
| JavaScript / TypeScript | tree‑sitter‑javascript | import { useState } from 'react' |
| Python | tree‑sitter‑python | from pathlib import Path |
| Go | tree‑sitter‑go | import "github.com/user/project" |
| Ruby | tree‑sitter‑ruby | require 'net/http' |
| Java | tree‑sitter‑java | import javax.sql.DataSource; |
| C# | — | using System.Net.Http; |
Privacy first: we never upload or persist your source code. The scan runs in our secure worker, extracts only module names, and discards the file contents immediately.
3. Dead vs. Alive
If a transitive module never appears in any import statement, we mark it dead. Then we walk the dependency graph:
- A dead parent marks its children dead—unless those children are also required by a live parent.
- Direct dependencies are always treated as alive, because we don’t scan user code deeply enough to guarantee otherwise.
The result is a crisp “used” or “unused” flag on every transitive package.
What You’ll See in the Product
Filter CVEs by Used Dependencies
In the Vulnerabilities tab you’ll notice a new toggle: Used dependencies only. Flip it on and watch the noise disappear—CVE counts drop to only the libraries that actually execute in your application.
Enabling the Feature
Module Reachability is already enabled by default for users on the free tier—no action needed. For paid plans, it’s currently opt-in via the Settings page. We’ve kept it optional during the beta since the additional source-code scan can add a small delay to SBOM generation. After the beta, Reachability will be enabled by default for all plans, with a toggle available if you prefer to turn it off. No additional configuration or build steps required.
When you enable Reachability, you'll see a significant reduction in noise—on average, 25–35% of transitive dependencies are filtered out as unused. That means fewer alerts, fewer false positives, and a shorter list of vulnerabilities to triage.
Updated about 13 hours ago