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. 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 Analysis Types

Socket offers 3 types of reachability analysis with increasingly better levels of false positive reduction.

The differences are as follows:

	Dependency Reachability (previously Tier 3)	Precomputed Reachability (previously Tier 2)	Full Application Reachability (previously Tier 1)
False positive reduction (varies between codebases)	Eliminate up to 35% false positives.	Eliminate up to 80% false positives in transitive dependencies.	Eliminate up to 90% false positives.
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.
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 package level. • Scans all dependency source code to determine which packages are imported/required.	• Eliminates unreachable vulnerabilities in transitive dependencies 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.
Availability	Available for customers on the Free, Team, and Enterprise plans.	Available for customers on the Team and Enterprise plans.	Available for customers on the Enterprise plan.

Reachability Ecosystem Support

Ecosystem	Package manager	Dependency Reachability (prev. Tier 3)	Precomputed Reachability (prev. Tier 2)	Full Application Reachability (prev. Tier 1)
JavaScript and TypeScript	npm, yarn, pnpm	✅	✅	✅
Python	uv, pip, Poetry, Anaconda	✅	✅	✅
Go	Go Modules	✅	✅	✅
Java	Maven, Gradle	✅	✅	✅
.NET (C# only)	Nuget, Paket	🌙 Not planned*	✅†	✅†
Scala	sbt, Maven, Gradle	✅	✅	✅ (Socket facts or CDX SBOM required)
Kotlin	Maven, Gradle	✅	✅	✅ (Socket facts or CDX SBOM required)
Ruby	Bundler	✅	✅	✅
Rust	cargo	🌙 Not planned	✅†	✅†
PHP	Composer	🌙 Not planned	✅	✅

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

†Note: For .NET and Rust, Full Application and Precomputed reachability operate at the class level rather than the function level. See Static Reachability Analysis for details.

Reachability Specifications: Human-Verified and AI-Generated

To determine whether a vulnerability is reachable, the precomputed and full application reachability analyses rely on a reachability specification for each vulnerability: a description of which parts of the affected package (usually specific functions) are responsible for it.

Every specification is produced by the same process. What differs is whether a human has confirmed its accuracy:

Human-verified: a reviewer on Socket’s reachability team has confirmed the specification. These are used by default.
AI-generated (also auto-inferred): generated and reviewed by Socket’s AI tooling, but not yet confirmed by a human. A specification often starts out AI-generated and becomes human-verified once a reviewer gets to it.

By default, Socket reports reachability using only human-verified specifications. Organizations can opt in to also use AI-generated ones. This broadens coverage (more of your vulnerabilities receive a reachability verdict), but because the patterns are not yet human-verified, there is a slightly higher risk of an incorrect reachability result. The opt-in applies to both precomputed and full application reachability.

An organization admin can enable it in the Socket Dashboard under Settings → Alert Scans → Reachability, using the AI-reviewed reachability patterns toggle. When enabled, each reachability result’s alert details show a Specification field labeled Human-verified or AI-generated.

For the full process behind each specification type, see How does Socket know which parts of a package are affected by a vulnerability? on the Static Reachability Analysis page.