Methodology & privacy

How DepCheck works

DepCheck reads the dependencies you paste — your package.json or lockfile — and tells you which ones are a liability: known vulnerabilities, typosquats, abandoned packages, risky licenses, and install-time footguns. This page explains exactly how each check works, what gets sent over the network (only names and versions — never your code), and what to do the moment you find a risky dependency.

• Privacy stance
• The checks
• How each check works
• Check → severity table
• Not a full audit
• I found a risky dep
• The ship-safety suite
• Roadmap

The privacy stance: only names and versions leave your browser

DepCheck needs to ask public registries two questions about your dependencies — "is this version known-vulnerable?" and "is this package real, fresh, and sensibly licensed?" To answer them, it sends only the package name and version number to public services. It never sends your source code, your .env, your secrets, your lockfile integrity hashes, or anything else from your project.

Concretely, that means:

• What is sent: coordinates like express@4.17.1 or left-pad@1.3.0 — the same strings already printed in every public npm page and in your committed lockfile.
• To whom: the OSV.dev vulnerability database and the public npm registry — both public, read-only lookups. No account, no API key, no DepCheck backend in the middle.
• What is never sent: your actual code, secrets, environment variables, private package contents, file paths, or any text beyond the dependency coordinates themselves. The parsing of your pasted JSON happens entirely in your browser.

The offline hygiene checks below don’t make any network request at all — they run purely on the text you paste. The only reason DepCheck talks to the network is to look up vulnerability and registry facts that simply don’t exist on your machine.

What DepCheck checks

DepCheck runs four families of checks across the dependencies you give it. Two of them (vulnerabilities and registry facts) require a public lookup by name and version; two of them (typosquats and hygiene) run entirely offline in your browser.

How each check works

1. Known vulnerabilities — OSV lookup

For every dependency, DepCheck queries the OSV (Open Source Vulnerabilities) database with just the package name and the exact version you have. OSV is Google’s open, aggregated feed of advisories — it folds in the GitHub Advisory Database, npm audit data, and ecosystem CVEs. If your version falls inside the affected range of a published advisory, the package is flagged with the advisory’s own severity (a remote-code-execution or prototype-pollution bug surfaces as Critical/High; a lower-impact issue as Medium). The fix is almost always "upgrade to the first patched version," which DepCheck shows you.

2. Typosquats — edit-distance heuristic

Attackers publish malware under names one keystroke away from popular packages — expres, crossenv, lodahs — hoping a fat-fingered npm install pulls the wrong one. DepCheck compares each of your dependency names against a list of high-traffic packages using Damerau-Levenshtein (transposition-aware) edit-distance — which also catches swapped adjacent letters, like loadsh for lodash. A name that is one or two edits away from a popular package — but isn’t that package — is flagged as a possible typosquat so you can double-check you installed the one you meant. This is a heuristic: a close name can be perfectly legitimate, so DepCheck surfaces it for review rather than condemning it.

3. Registry freshness & license — npm metadata

Using the same name-and-version lookup, DepCheck reads public metadata from the npm registry to judge two things. Freshness: when was the package last published? A dependency with no release in years may be unmaintained — abandoned packages don’t get security fixes, and an idle, popular package is a prime target for a hijacked-maintainer supply-chain attack. License: what license does it ship under? A missing license, or a copyleft/commercial license you weren’t expecting (e.g. GPL in a closed-source product), is flagged so legal surprises don’t reach production.

4. Offline hygiene checks

These run on the pasted text alone, with no network call:

• Install scripts & risky ranges. When you paste a raw package.json, DepCheck inspects its scripts block and flags preinstall/install/postinstall (and other lifecycle hooks) that run code automatically on install. Version specifiers so loose they’ll silently pull a brand-new (unvetted) release are surfaced the same way, as install-time risk.
• Git / URL / wildcard dependencies. Deps pointing at a raw git URL, a tarball, or "*" bypass the registry’s integrity and versioning guarantees and are flagged for review.
• Pinning & lockfile hygiene. Unpinned ranges on sensitive packages, or a manifest with no lockfile discipline, are noted as reproducibility/supply-chain hygiene findings.

Check → what it flags → severity

Severity reflects how dangerous a finding typically is. For vulnerabilities, DepCheck inherits the advisory’s own rating; for the heuristics, the defaults below apply. Treat these as representative, not exhaustive.

The exact rule set and the popular-package list evolve; treat this table as representative, not exhaustive. Severities are defaults and reflect typical risk, not your specific architecture.

This is heuristic detection — not a full audit

Like every heuristic scanner, DepCheck can produce both kinds of error:

• False negatives. A brand-new vulnerability not yet in OSV, malware hiding under a name nowhere near a popular one, or a deeply nested transitive dependency you didn’t paste can all slip past unflagged.
• False positives. A close-but-legitimate package name, an intentionally pinned old version, or a license that’s perfectly fine for your use can be surfaced when there’s nothing actually wrong.

DepCheck looks at the dependency coordinates you give it — not your full installed tree, your build pipeline, your runtime config, or your threat model. Use it as a quick first pass before you ship, alongside npm audit, a lockfile, and a real review. If you need genuine assurance, talk to Copper Bay Labs.

I found a risky dep — now what?

Don’t panic, and don’t blindly delete it. Work the finding in order:

1. For a known vulnerability: upgrade to the patched version. Bump to the first fixed release DepCheck names (or run npm audit fix), then re-test. If no fix exists yet, check whether you actually call the vulnerable code path and consider an override or an alternative package.
2. For a possible typosquat: confirm you installed the right package. Compare the name against the popular package character-by-character, check the npm page’s weekly downloads and repository link, and if it’s the wrong one, remove it and reinstall the correct name immediately — assume the typosquat ran malicious install code.
3. For an abandoned package: find a maintained alternative. An unmaintained dependency won’t get security fixes. Look for an actively released replacement, or vendor/fork it if you must keep it.
4. For an install script or git/URL dep: review what it does. Read the lifecycle script and the source before trusting it; pin it to an exact, audited version and prefer a registry release over a raw URL.
5. For a license surprise: resolve it before you ship. Swap to a permissively licensed alternative, or confirm with whoever owns licensing that the terms are acceptable for your product.
6. Then pin and lock. Commit a lockfile, pin sensitive dependencies to exact versions, and re-scan so your fix is reflected. Reproducible installs are what stop the next surprise.

Part of the Copper Bay Labs ship-safety suite

DepCheck is one of four free, client-side tools that each answer a different "will this ship safely?" question for vibe-coded and indie apps. They’re siblings — use them together before you launch.

On the roadmap

Scan your dependencies now