FAQ

Straight answers.

Including the parts most vendors gloss over — what isn’t built yet, and when you might not need us.

Common questions

What does depproof actually do today?

It resolves the full transitive dependency tree — Maven directly from source with no build, Gradle after your build, npm and Python from the lockfile, and Go from its module graph — classifies every dependency’s license (allowed, review, or forbidden), screens it against OSV advisory data, and produces a self-contained HTML report plus a CycloneDX SBOM — as a GitHub Action or a single self-hosted container.

Which ecosystems are supported?

Four today: the JVM (Maven and Gradle), JavaScript/Node (npm, pnpm, yarn, and bun), Python (PyPI), and Go (modules). npm and Python resolve the full tree straight from the lockfile with no install, and Go from the project’s own module graph; the JVM came first because that’s where accurate transitive resolution is hardest. Each one is added deeply rather than broadly — language is our beachhead, not the moat.

Do you need my source code or send it anywhere?

No. depproof runs on your own infrastructure — in your CI or on your machine. Your code and your findings never leave it. There is no depproof cloud to send data to and no subprocessor to add to a vendor review. On its own, the scanner identifies advisories and licenses by looking up dependency coordinates — a package name and version, never your source — against public sources (OSV.dev, ClearlyDefined, and package registries such as Maven Central). With the depproof hub, advisory and license lookups go to your own hub instead, and the hub fetches each package once for your whole organization. No account, no API key, no telemetry.

Does depproof tell dev dependencies apart from what ships?

Yes, wherever the project declares it. depproof reads the declared scope of every dependency in every ecosystem that states one — Maven’s test and provided scopes, Gradle’s test configurations, npm’s devDependencies — and reports what ships and what does not. Where nothing is declared, it says so: go.mod records no scope at all, and neither does a Gradle version catalogue, so those dependencies are counted as undetermined rather than assumed. Dev dependencies are ranked lower, not hidden; the scope filter exists and is off by default. (Are dev dependencies a security risk? explains why.)

Why open data (OSV) instead of a proprietary vulnerability database?

Proprietary databases lock your findings to one vendor and can’t be independently audited. depproof builds on OSV.dev — open, portable advisory data — so you can switch tools or hosts and keep your governance. Better data underneath, no lock-in on top. (OSV vs CVE explains why package-keyed data, not CVE/CPE data, is what a scanner can actually match against your lockfile.)

How is the pricing different?

You pay for the depproof products you use — the Scanner, and the Hub added to it — never per seat, per committer, or per application. Every developer and every repository is included, and the Scanner is free for open source and organizations under $1M in revenue. Per-seat pricing pushes teams to under-scope coverage; pricing by product lets you scan 100% of your repos without a budget penalty. See pricing.

Do you have an org-wide dashboard and blast-radius search?

Yes — the depproof hub. It’s a self-hosted aggregation hub you deploy inside your own network and own outright; it rolls up depproof’s reports across all your repos into one cross-repo view — blast-radius search (“is this CVE anywhere in our estate, and where?”), org-wide license posture, and a current SBOM for any product on request. Same posture as the scanner: your evidence never leaves your infrastructure.

How is the hub different from a SaaS dependency dashboard?

SaaS governance platforms ingest your dependency graph into a vendor cloud and price per developer or per application. The depproof hub gives you the same org-wide dashboard and blast-radius search on your own infrastructure, owned by you, priced per product rather than per developer — and it doesn’t need a platform team to run.

How do I get the hub?

The hub is a depproof product you add to the Scanner, for regulated organizations and teams with many repositories that need org-wide governance on their own infrastructure. See pricing, or tell us about your estate from the hub page and we’ll be straight with you about fit.

How is this different from Snyk, Nexus, or GitHub/GitLab governance?

Snyk is powerful but SaaS and per-developer. Nexus is self-hostable but heavy and per-application. GitHub/GitLab governance is native but locks you to one host and its premium tier. depproof is the host-agnostic, self-hosted, open-data option you don’t need a platform team to run, priced per product rather than per developer. If you’re happily all-in on one of those, you may not need us — and we’ll say so. Free, self-hosted tools are a different category from these paid options; where one of them answers your question, it is the right answer.

Is it heavy to operate?

No. It’s a single container that scans and exits — nothing to install on your build agents, and nothing left running between scans. That’s deliberate: the self-hostable alternatives in this category expect a standing service with an HA story and platform expertise to keep it up, which is a different order of commitment from running one image in CI.

How accurate is the JVM dependency resolution?

For Maven, depproof resolves the complete transitive tree with the same accuracy as an ecosystem-native build — no build step and no lockfile. Gradle build scripts are programs, so Gradle projects are resolved after your build. Either way you avoid the caveats you hit elsewhere, where accurate resolution needs a successful build or dependency-submission.

Still weighing it up?

Tell us about your estate — hosts, ecosystems, constraints — and we’ll be honest about whether depproof is the right fit.

Write to hello@depproof.com — a real person reads it.