Introducing Module Reachability: Focus on the Vulnerabilities That Matter
Module Reachability filters out unreachable CVEs so you can focus on vulnerabilities that actually matter to your application.
Trevor Norris
April 23, 2025
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.
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:
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.
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.
Rust is next on our roadmap. As we add new language runtimes to the platform, Reachability will automatically expand to cover them—no action needed on your part.
And this is just the beginning!
Today’s release marks the first iteration of Reachability in Socket, but we’re about to take things to the next level. With our recent acquisition of Coana, the best-in-class reachability engine, we’re bringing industry-leading static analysis and precision to Socket’s platform.
In the coming months, we’ll be turbocharging Reachability with Coana’s technology: faster performance, deeper analysis, and dramatically fewer false positives. Soon, every Socket user will benefit from Coana’s precomputed reachability engine, with no configuration and no friction, just smarter, more actionable vulnerability alerts.
TC39 advances 9 JavaScript proposals, including Array.fromAsync, Error.isError, and Explicit Resource Management, which are now headed into the ECMAScript spec.