R-SOC
socket.dev
Scans open-source dependencies for malware, typosquatting, and other supply-chain risk.
OVERVIEW
Socket (socket.dev) analyzes open-source packages across npm, PyPI, Go, and other ecosystems for supply-chain risk that traditional CVE-based scanners miss entirely: install/postinstall scripts that reach out to the network, obfuscated code, typosquatted package names, sudden maintainer changes, and use of dangerous APIs like filesystem or shell access in a package that shouldn't need them.
It ships as a GitHub app that comments on pull requests with risk scores for newly added dependencies, plus a standalone `socket` CLI for local scans and CI gating, so it fits into an assessment either as a one-off scan of a client's manifest or as a recommendation for ongoing dependency monitoring.
USE CASES
Practical use cases
- 01
Scanning a project's package manifest for known-malicious or typosquatted dependencies.
- 02
Flagging packages with install scripts that make unexpected network or filesystem calls.
- 03
Reviewing pull requests that add new dependencies before they're merged into main.
- 04
Recommending ongoing dependency monitoring as a finding remediation for a client's CI/CD pipeline.
QUICK START
When assessing an application's software supply chain, to catch malicious or suspicious open-source packages that a vulnerability scanner alone wouldn't flag.
- Confirm the client's repository or manifest files are in scope for dependency scanning.
- Install the socket CLI, or connect the GitHub app to a scoped repository for a one-off review.
- Run a scan against the project's package manifest to get a risk report.
- Manually review flagged packages for context — a risky permission isn't always malicious — before reporting.
npx socket npm installBEFORE YOU RUN IT
What to check before running it
Socket's free tier covers public open-source scanning; scanning a client's private manifests at scale over time typically needs a paid plan — confirm licensing before committing to it as a recurring deliverable.
A risk flag (e.g. a package requesting filesystem access) is a signal, not proof of malice — many legitimate packages need the same permission, so review context before reporting a package as malicious.
Like any SBOM/dependency scan, results reflect what's declared in the manifest at scan time — confirm lockfiles are current so the scan isn't missing recently added or updated packages.