Don’t trust the registry. Verify the code.
Catch install script abuse, credential theft, typosquats, and supply chain malware patterns before they touch your system.
$npm install -g @westbayberry/dg
No account needed. Run it locally in seconds.
Scan any package. Right now.
Type a package name and see what our detectors find. No account needed.
How Dependency Guardian works
Every package is analyzed for behavior, correlated across signals, scored for risk, and returned as a clear pass, warn, or block verdict.
Update
Tarball
Metadata
Sandbox
Correlation
confidence
-
01Intake
Dependency Update
A new package or version enters the pipeline.
-
02Retrieve
Fetch Tarball
The registry tarball is pulled down for inspection.
-
03Analyze
Static Detectors
Every file scanned by five detector categories, plus sandbox routing for eligible packages.
-
04Correlate
Cross signal Correlation
Detector signals combine into high confidence attack patterns.
-
05Score
Risk Scoring
Adaptive 0 to 100 risk score per package.
-
06Decide
Verdict
Score maps to one of three verdicts, each with its own delivery path.
PASS0 to 39 WARN40 to 69 BLOCK70 to 100 -
07Deliver
Delivered
Verdicts reach developers wherever they work.
A friendly CLI.
A quiet GitHub App.
Install once and Dependency Guardian shows up where you already work, your terminal, your pull requests, your CI.
Setup in 60 seconds
Welcome. I'm Dependency Guardian.
Want me to show you how I work?
Any one of your packages could be stealing passwords
in the background. For months before anyone notices.
Let me show you what happens when you're using a malicious package — and using Dependency Guardian.
Supply-chain attacks aren't rare anymore — and they're rising fast. 454,600+ new malicious packages in 2025 800+ npm packages from North Korea's Lazarus Group (2025) 500+ developers hit by one self-replicating npm worm Sources: Sonatype 2026 SSC Report · Datadog Security Labs · Microsoft Security
Two ways to wire me in. Same engine.
On the PR check list: ✓ Build ✓ Lint ✘ Dependency Guardian Not_a_cryptominer · 100 Branch protection blocks the merge.
In your terminal: $ dg scan ✘ block · 1 flagged $ pip install not_a_cryptominer ✘ blocked at install Works locally and in any CI.
$ ▋ Scanning packages… ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
Here's what I did to Not_a_cryptominer: [ ] fetched the tarball from npm [ ] detectors flagged a net-exfil call [ ] sandbox saw outbound DNS at install [ ] correlator matched a known C2 pattern [ ] score = 100 [ ] verdict ─▶ block
Gate `npm/pip install` itself: Covers these install paths: dg npm · dg pip · dg uv dg pnpm · dg cargo setup shims · service proxy $ dg npm install Not_a_cryptominer → ✘ block
Install adds only the dg binary. Use dg npm install / dg pip install for zero-footprint prefix protection, run dg setup --yes for user-local shims, or start service mode for configured absolute-path protection.
Your code never leaves your machine.
Sent: package names + versions
I pull tarballs from npm / PyPI directly.
Pricing. Same engine, every tier. Free $0 50,000 packages / mo · full detection engine Pro $15 / mo 250,000 packages · watchlists · priority support Team $10 / user unlimited packages · policy · Slack + webhooks
Ready to be more secure? Two ways to start:
Free tier: 50,000 packages / month. Curious about anything? read the docs!
$npm install -g @westbayberry/dg
Common questions
Answers to the questions security teams ask before adopting a new dependency scanner.
What if Dependency Guardian itself gets compromised?
Defense in depth. The CLI is a thin API client. Detection runs server side, not in your CI. Every downloaded package is cryptographically verified against the registry before analysis. Webhook deliveries are signed and verified at both ends. The CLI only sends lockfile diffs and receives JSON verdicts. It cannot execute arbitrary code in your CI.
Is my source code sent to your servers?
No. The system receives package names and versions from your lockfile diff, then fetches package tarballs directly from the public registry. Your application code never leaves your environment.
Does it work outside GitHub?
Yes. Install the CLI (npm i -g @westbayberry/dg), run dg scan in any CI or
locally. Same engine, same detectors.
Can I configure it for PRs only, not main?
The GitHub App scans every PR and posts a Dependency Guardian check run with a pass, neutral,
or failure conclusion. It does not push block main. What blocks a merge is your own
branch protection rule against that check. If you use the CLI directly, you control when and where it runs
from your CI pipeline.
Which package managers are supported?
JavaMaven
RubyRubyGems
.NETNuGet
GoGo modules
RustCargo
ScalaMaven / sbt
KotlinMaven / Gradle
PHPComposer / Packagist
C / C++Does it work with monorepos?
Yes. Single lockfile workspaces work out of the box. For multi lockfile monorepos, pass
--workspace <dir> on the CLI (or set DG_WORKSPACE) to scope a scan to one
project, or configure path patterns in the dashboard for the GitHub App.
Can I run DG from the command line?
Yes. Install globally with npm install -g @westbayberry/dg (or run via
npx @westbayberry/dg). Authenticate with dg login (prints a verification URL
and opens your browser when you press ENTER), then run dg scan. A scan covers every
package in your lockfiles, including nested projects in a monorepo. The CLI is flag-free —
output is human-readable by default; use --json or --sarif for CI. For install protection,
use dg npm install / dg pip install, run dg setup --yes for user-local shims,
or use explicit service mode for configured absolute-path package-manager calls.
