Socket

What it is #

Socket is a commercial security product built specifically to detect supply-chain attacks in open-source dependencies. It contrasts itself explicitly with vulnerability scanners (which match package versions against CVE databases after the fact) and with traditional static analysis tools (which target a developer’s own code). Socket targets the third-party code a project depends on, before it is merged into the project’s package manifest.

The product is built by a team of open-source maintainers and operated as a hosted SaaS. The analysis engine is proprietary; the CLI is open-source. Public-repo scanning and per-package “health score” search on socket.dev are free; private-repo coverage beyond a first repository is paid.

Ecosystems currently supported: JavaScript (npm), Python (PyPI), Java (Maven), Ruby (RubyGems), .NET (NuGet), Go (modules), Rust (Cargo), Scala, and Kotlin, with PHP, Swift, and Objective-C in development. Coverage is significantly broader than most peers in this category.

Analysis model #

Socket combines three techniques:

Static analysis. A custom in-house engine parses each package’s source and looks for usage of privileged APIs (network, shell, filesystem, eval(), environment variables) and for code patterns associated with malicious behaviour (obfuscation, high-entropy strings, suspicious install scripts, telemetry). The detection extends transitively through the dependency graph: a package is flagged for “uses-network” if any of its transitive dependencies opens a socket, not only if its own code does. Socket calls this capability detection.

Package metadata analysis. Socket inspects signals independent of the code itself: typosquat detection (Levenshtein distance to popular package names, weighted by download-count ratios), detection of packages that load remote code at install or runtime (which bypasses lockfile pinning), and other manifest-level red flags.

Maintainer behaviour analysis. Socket tracks side-channel signals about the people publishing packages: new maintainers with no history, publish-permission changes (“unstable ownership”), out-of-chronological publishes (where patches land on old major versions still in heavy use), unmaintained projects, and similar.

In total Socket lists 70+ signals across these three techniques. The analysis is static today; the FAQ mentions dynamic analysis as a planned addition. Because the engine does not execute code, it cannot observe runtime-only behaviour, and obfuscation techniques designed to evade static detection remain a structural limit.

Workflow #

Producer side: Socket continuously analyses every published version across the supported registries. There is no per-package opt-in or opt-out; coverage is determined by Socket’s ingest, not by maintainer or consumer requests.

Consumer side: the headline integration is the Socket GitHub App, which leaves PR comments whenever a dependency change introduces a new risk signal. The comment surfaces the specific signals (new install script, new network access, typosquat suspicion) so the reviewing developer can decide whether to merge. Socket also provides a CLI, a REST API, and a free web interface at socket.dev for per-package health-score lookups.

Comparison to OpenVet #

OpenVet and Socket answer different questions about a dependency. OpenVet asks “has a trusted reviewer asserted specific properties of this code?”, a question that requires a human to read code and sign claims. Socket asks “does the code or its metadata look like a supply-chain attack indicator?”, a question that an automated heuristic engine can answer at registry scale. Both questions are useful and they catch different things.

The structural differences:

Operating model. Socket runs automated heuristic analysis on every published package; coverage is the responsibility of Socket’s ingest. OpenVet audits are human-authored: an auditor reads the code and signs claims about specific properties. OpenVet itself does not run any checks, it only provides the tooling and the hosting for audits.

Output shape. Socket produces categorical signals and a package health score: flags like “install script”, “uses network”, “typosquat suspect”, and capability tags. Capabilities are computed transitively over the dependency graph: a package is flagged uses-network if its own code or any of its transitive dependencies opens a socket. OpenVet auditors produce structured claims (impl-crypto, uses-network) describing what the package itself does; the same label is narrower in OpenVet than in Socket. The design follows from how dependency resolution works: packages bind to version ranges rather than exact dependencies, and the resolved set is only known on the consumer side, so a transitive flag attached to a package at publish time would either need to enumerate every possible resolution of its range constraints (intractable) or be valid only against one specific resolution. OpenVet sidesteps this by performing aggregation per-consumer against the lockfile, which gives exact claims for the resolved dependency set.

Coverage trigger. Socket covers every release on every supported registry, continuously. OpenVet covers dependencies that a human has chosen to audit; coverage grows with effort rather than automatically.

Consumer interface. Socket’s consumer surface is GitHub PR comments, a CLI, a REST API, and a public web search at socket.dev. OpenVet output is delivered as content-addressed audit trees fetched against the consumer’s lockfile by the OpenVet CLI.

Ecosystem. Socket covers JavaScript, Python, Java, Ruby, .NET, Go, Rust, Scala, and Kotlin, with several more in development. OpenVet covers Cargo, npm, PyPI, Go modules, and RubyGems.

Open vs proprietary. Socket’s analysis engine is in-house and not publicly inspectable; running Socket means trusting both the methodology and Socket Security as a service operator. The CLI is open-source and package health scores are accessible through the free web interface, but the core analysis runs as a hosted service with paid private-repo plans. OpenVet is an open standard with open-source tooling and a public registry; the methodology is inspectable, anyone can run a log, and there is no commercial dependency on a single operator.

Using alongside OpenVet #

OpenVet is intended as a replacement for Socket, with stronger guarantees: a signed human audit assertion is more verifiable than a heuristic inference, and an auditor can express findings with context (intent, scope, nuance) that a pattern-matching engine cannot. A complete OpenVet adoption removes the need for Socket-style heuristic scanning on the audited slice of a project’s dependency graph.

Until audits exist for a given dependency, however, Socket is useful in two ways alongside OpenVet.

For a consumer using a dependency that has not been audited (or has not been audited by a publisher the consumer trusts), Socket is a stop-gap. Its PR-comment integration surfaces signals inline at exactly the point where the decision to add the dependency is being made, which makes it directly actionable. Heuristic signals do not replace a review, but they are better than no signal at all on a package nobody trusted has looked at.

For an auditor producing an OpenVet audit, Socket’s signals and capability detection are a useful input to the review, particularly when capabilities or behaviour change between releases. A release where Socket newly flags “uses shell” or “uses network” is a release where the audit should account for what changed and either explain it or surface it as a finding.