depproof

Article · Supply chain

Dependency governance: when per-repo scans stop being enough

For a while, per-repo scans are enough. Then you land a regulated customer, start a SOC 2, or a Cyber Resilience Act obligation lands — and overnight the questions turn org-wide: which of our products ship this newly-disclosed CVE, and can we produce a current SBOM for any of them on demand? You can only answer those if the scan data is aggregated in one place and the inventory underneath is accurate. That aggregate — and the policy on top of it — is what dependency governance actually is.

Updated 23 Jul 2026 · by the depproof team

The problem isn’t scanning — it’s that the results are scattered

Most engineering orgs already scan. Dependabot flags a repo, a CI job emits an SBOM, someone runs a license check before a release. The gap isn’t coverage of any single project — it’s that each result lives in isolation. Nobody has collected them, so nobody can answer a question that spans the estate:

  • “A critical CVE just dropped — are we exposed, and where?” Answering this by opening forty repos one at a time is how a same-day patch becomes a two-week fire drill.
  • “Which of our products ship an AGPL or other copyleft component?” A per-repo scan can catch it locally; only an aggregate tells you the blast radius across everything you ship — and whether AGPL is safe for your commercial or SaaS use depends on how you use it.
  • “Give me a current SBOM for product X.” When a customer or auditor asks, you need it on demand — not a scan you kick off and hope finishes clean.

These are governance questions, and they’re all aggregate questions. The unit of value isn’t the individual scan; it’s the collected, queryable inventory across every repo.

What aggregation buys you — security and compliance

Pulling every project’s dependency data into one place pays off on two fronts that a team crossing into compliance feels directly.

Security: response time and blast radius

The value of a dependency inventory is proven on the day a widely-used component is found vulnerable — a Log4Shell-shaped event. With an aggregate you query one place: which artifacts, in which repos, at which versions. Without it, incident response starts with an archaeology dig across repositories before you can even scope the work. Continuous monitoring of the aggregate — re-checking known components against new advisories — turns “we’ll audit next quarter” into “we knew within the hour.”

Compliance: evidence you can produce on demand

Compliance regimes and customer security reviews increasingly ask for two things: a machine-readable SBOM, and evidence that you monitor components over time. The EU Cyber Resilience Act obliges manufacturers to produce a machine-readable SBOM; procurement teams ask for one before they’ll sign; SOC 2 and vendor questionnaires ask how you track open-source risk. An aggregated inventory lets you generate a current SBOM for any product on request and show coverage across the estate — the difference between passing an audit and scrambling through it.

The dashboard is only as good as the data under it

It’s tempting to treat governance as a dashboard-shopping exercise. But an aggregate view inherits the accuracy of the inventories feeding it — and for the JVM, that’s exactly where most tools are weakest. Native Java dependency resolution is caveated everywhere: transitive versions resolved differently than the build would, optional and provided scopes mishandled, version ranges guessed. A pretty dashboard built on a dependency graph that doesn’t match what you actually ship gives you confident wrong answers — arguably worse than no dashboard.

So the order of operations matters: get the per-repo inventory right first, then aggregate. For Maven that means resolving the full transitive tree so it matches what your build actually ships — which is the one thing depproof is built to do.

How to get there without a six-figure platform

The incumbent platforms bundle generation, aggregation, a dashboard, and policy — and price it per contributor or per seat, quote-only, often into six figures a year even for a sub-100-developer shop. You don’t have to buy the bundle to get the outcome. Governance decomposes into two functions you can assemble from focused, self-hostable pieces:

  • Generate an accurate SBOM per repo. This is the data layer — and across the JVM (Maven, Gradle), JavaScript/Node (npm, pnpm, yarn, bun), Python (PyPI) and Go (modules), depproof resolves the full transitive tree — Maven with no build, npm and Python straight from the lockfile — as a GitHub Action or a single container, on your own infrastructure.
  • Aggregate and monitor. The depproof hub — self-hosted inside your own network and owned by you — consolidates those reports into one cross-repo inventory and re-checks components against new advisories over time.

Both halves are self-hosted, so no source and no dependency graph leaves your network — the posture regulated and security-conscious buyers require. It’s a deliberately un-flashy stack, and it answers the governance questions above without a metered platform bill.

Where depproof fits — and where it doesn’t

Being precise about scope, because governance claims are easy to overstate:

  • depproof is the generation / data layer. It produces the accurate CycloneDX SBOM per repo. That is the input good governance depends on.
  • Org-wide aggregation and cross-repo blast-radius search ship in the depproof hub — a self-hosted control plane you deploy inside your own network and own outright, so the aggregate view never leaves your infrastructure.
  • Four ecosystems today. depproof covers the JVM (Maven, Gradle), JavaScript/Node (npm, pnpm, yarn, bun), Python (PyPI) and Go (modules). A fully polyglot estate — container layers, other runtimes — still needs generators for those too; the depproof hub aggregates the reports depproof produces across your repos.

Start with accurate data

Governance is a program, not a purchase, and it stands on the quality of the inventory underneath. The pragmatic first step for any team facing this isn’t buying a platform — it’s making sure every repo emits a correct SBOM you can trust once it’s aggregated. From there:

Frequently asked questions

What is dependency governance?

Dependency governance is the practice of managing open-source dependency risk — license, known-vulnerability, and supply-chain risk — as an org-wide program rather than one repo at a time. In practice it means generating a consistent inventory (an SBOM) for every project, aggregating those inventories into one queryable view, and setting policy on what is and is not allowed. A single-repo scan is a data point; governance is the aggregate and the policy on top of it.

Why aggregate dependency scan data instead of scanning each repo?

Because the questions that matter at a company level are cross-repo. "Is this newly disclosed CVE anywhere in our estate, and where?" and "Which products ship a copyleft license we prohibit?" cannot be answered by a per-repo scan that nobody has collected. Aggregation turns dozens of isolated scan results into one inventory you can search — which is what security incident response and compliance audits actually need.

Do you need a platform like Sonatype or Snyk to do this?

No. Both halves are self-hosted depproof. The scanner generates the accurate SBOM per repo for the JVM (Maven, Gradle), JavaScript/Node (npm, pnpm, yarn, bun), Python (PyPI) and Go (modules) — Maven with no build, npm and Python straight from the lockfile, Gradle after your build — and the depproof hub, deployed inside your own network and owned by you, aggregates those reports across every repo into one queryable inventory it monitors over time. Self-hosted end to end, without the metered per-contributor pricing of the incumbent platforms.

Does depproof provide the org-wide dashboard?

Yes — the depproof hub. depproof generates the accurate CycloneDX SBOM per repo, and the depproof hub aggregates those reports across your estate into one cross-repo view — blast-radius search and org-wide license posture. It’s self-hosted inside your own network and owned by you, so the aggregate never leaves your infrastructure.

What does aggregated dependency data give you for compliance?

A defensible, machine-readable record. Regulations and customer security questionnaires increasingly ask for an SBOM and evidence that you monitor components for new vulnerabilities. An aggregated inventory lets you produce a current SBOM for any product on request, show coverage across the estate, and demonstrate continuous monitoring rather than a one-off scan — the difference between passing an audit and scrambling for it.

Start your first audit → Read the docs

depproof is free for open source and teams under $1M revenue — see pricing. The action README is the source of truth for exact inputs and the current release. depproof is not affiliated with Sonatype or Snyk; product names are used nominatively.