Two different layers: Socket watches your dependency graph and the public registries on an ongoing basis for 70+ risk types, risky install scripts among them. This tool reads two point-in-time copies of your own package-lock.json (or your local node_modules), once, locally, and names exactly which packages run a lifecycle script and which ones gained one since your last check — no account, no registry calls, nothing installed.
Socket is a supply-chain security platform. Its own site describes deep package inspection that characterizes what a dependency actually does, rather than relying only on known-vulnerability databases, connected through a GitHub app, a CLI, and a browser extension. It flags more than 70 categories of risk across npm, PyPI, and other ecosystems — risky install scripts, typosquatting, malware, hidden or obfuscated code, and permission creep among them — and monitors changes to a project's dependency manifest on an ongoing basis. It is free for public, open-source use, and Socket's own site lists paid Team, Business, and Enterprise tiers for private-repository and organization use; today's specific prices and contract terms are not repeated here, since this session cannot verify them live against Socket's own site — only its well-documented product shape is described.
This tool does none of what Socket does. It has no account, no ongoing
service, no GitHub app, and no connection of any kind to a package
registry — it cannot tell you whether a name is actually
published anywhere, let alone whether it behaves maliciously. It reads
only what your own lockfile (or node_modules) already
declares: which packages run a preinstall,
install, postinstall, or prepare
script, and — given an older snapshot — exactly which ones
gained one since then, the mechanism behind the ua-parser-js (2021),
coa/rc (2021), and Shai-Hulud (2025) npm supply-chain attacks. Paste
the files you already have, or run the CLI against a checkout, and get
every finding with its fix — free, in your browser or a
zero-dependency script, with nothing uploaded and no network calls of
its own.
| Question | Where to answer it |
|---|---|
| I want continuous, registry-aware scanning of my whole dependency graph for malware, typosquats, permission creep, and dozens of other supply-chain risks — not just install scripts. | Socket — that is the ongoing, cross-ecosystem job it is built for. |
| I want to know right now, for free, which packages in this lockfile run a script at install time, and which ones are new since my last check. | This tool — paste two lockfiles, get the diff, nothing installed. |
| I want a GitHub app or CLI that watches every future pull request for newly introduced risky dependencies. | Socket — this tool has no memory between runs beyond the snapshot files you keep yourself. |
I want zero network calls and nothing to install to check a package-lock.json or node_modules tree I already have. | This tool — it never queries a registry, GitHub, or anywhere else. |
| I want to know whether a specific package has ever shown malicious behavior, or is a typosquat of a popular name. | Socket — this tool makes no registry calls and cannot answer that. |
| I want a one-time, local diff of exactly what changed about install-time scripts between two snapshots, with the risky-pattern flags on each. | This tool — that is the whole job, and the only one it does. |
A team can reasonably run both: Socket for continuous, registry-aware defense against a live attack already under way, and this tool as a fast, zero-account, zero-network gate — in CI, at release time, or by hand — over exactly the install-script surface a lockfile diff already tells you the truth about. This page does not evaluate Socket's detection accuracy and makes no claim about it either way — it only describes Socket's documented product shape and states what this tool does differently. Socket catching a live malicious package and this tool flagging a newly gained lifecycle script are two different signals; neither replaces the other, and a clean result from either one is not a supply-chain security guarantee.
This tool needs no account and no sign-in: it is a static page, the check runs in your browser (or as a stdlib-only CLI script), and it keeps working with the network connection off.
Not in the way this tool does. Socket's own site describes deep package inspection and real-time monitoring across more than 70 risk categories — including risky install scripts, typosquatting, hidden code, and permission creep — by watching your dependency graph against live registry data through a GitHub app, CLI, or browser extension. That is ongoing, registry-aware monitoring. This tool does the opposite and narrower thing: it never queries a registry or GitHub at all, and instead diffs two point-in-time copies of your own package-lock.json (or reads your local node_modules) to name exactly which packages declare a preinstall, install, postinstall, or prepare script, and which ones gained one since an older snapshot.
They work at different layers, and a team can reasonably run both. Socket runs on an ongoing basis against your dependency graph and the public registries, watching for a live attack across dozens of package-behavior signals, as a service that is free for public open-source use and offers paid plans for private and organization use, per Socket's own site; connecting it needs a GitHub app, CLI, or browser extension. This tool answers one narrower, factual question with nothing to connect: did any package in this exact lockfile gain an install-time script since the last time I checked? Free, no account, no registry calls, works with the network off.
No. This page is not affiliated with, endorsed by, or sponsored by Socket, Inc. Socket is a trademark of Socket, Inc., named here only to describe what this tool is and is not, based on Socket's own publicly documented product.
Open the npm Lifecycle Script Check to scan your own lockfile, or read why npm audit doesn't catch this for the full mechanism and how to wire the CLI into CI.