Socket SCA with Reachability Analysis allows you to safely disregard unreachable vulnerabilities and easily patch the ones that matter.

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.

Reachability Analysis changes that. By understanding which dependencies your application actually uses, Socket filters out CVEs that can’t affect you — allowing you to 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 identify the vulnerabilities that really matter to their application.

We developed reachability analysis to fundamentally change this dynamic.

Key features

Based on top-tier research.
Scans direct and indirect dependencies.
Works with any CI platform. No complex configurations. No agents required.

Before Socket = Overwhelming Noise

Traditional SCA tools do not distinguish between exploitable and unexploitable vulnerabilities. As a consequence, more than 80% of the vulnerabilities that developers are remediating are irrelevant and can be safely ignored.

After Socket = Clean Signal

Socket employs Reachability Analysis to eliminate more than 80% false positives. As a consequence, developers only need to remediate the remaining few vulnerabilities that are relevant.

Reachability Maturity Levels

Socket language ecosystems are classified into three maturity levels for Reachability Analysis.

The differences are as follows:

	Tier 3 — Module Reachability	Tier 2 – Dependency Function-level Reachability	Tier 1 – Full Application Function-level Reachability
False positive reduction (varies between codebases)	Eliminate 35% false positives.	Eliminate 60% false positives.	Eliminate 80% false positives.
Direct vs. Transitive	Identify reachable vulnerabilities in transitive dependencies.	Identify reachable vulnerabilities in transitive dependencies.	Identify reachable vulnerabilities in both direct and transitive dependencies.
Reachability	• Eliminates unreachable vulnerabilities at the module and file level. • Scans all dependency source code to determine which modules are imported/required.	• Eliminates unreachable vulnerabilities at a function level on dependency code. • Scans all dependency source code to determine which functions are called through your direct dependencies.	• Eliminates unreachable vulnerabilities at a function level on application and dependency code. • Pinpoints the exact locations in your code affected by reachable vulnerabilities.
Works out of the box	Yes. Works via all Socket integrations (API, CLI, Socket for GitHub, etc.)	Yes. Works via all Socket integrations (API, CLI, Socket for GitHub, etc.)	No, but easy to setup. Need to add a CLI command or GitHub Action to the repository.
Availability	Available for customers on the Free, Team, and Enterprise plans.	Available for customers on the Free, Team, and Enterprise plans.	Available for customers on the Enterprise plan.

Reachability ecosystem support

Ecosytem	Package manager	Tier 3 — Module Reachability	Tier 2 – Dependency Function-level Reachability	Tier 1 – Full Application Function-level Reachability
JavaScript and TypeScript	npm, yarn, pnpm	✅	🚧 In Progress (Q2)	⏳ Planned (Q3)
Python	uv, pip, Poetry, Anaconda	✅	🚧 In Progress (Q2)	⏳ Planned (Q3)
Go	Go Modules	✅	🚧 In Progress (Q2)	⏳ Planned (Q3)
Ruby	Bundler	✅	🚧 In Progress (Q2)	⏳ Planned (Q3)
Java	Maven, Gradle	✅	⏳ Planned	⏳ Planned
.NET (C#, F#, Visual Basic)	Nuget, Paket	🌙*	⏳ Planned	⏳ Planned
Scala	sbt, Maven, Gradle	✅	⏳ Planned	⏳ Planned
Kotlin	Maven, Gradle	✅	⏳ Planned	⏳ Planned

*Note: Our research has shown that NuGet published packages have a low likelihood to contain extra dependencies that are detectable at the module level. As a result, we’re focusing on improved detection through Tier 2 Reachability instead.