depproof

Solution · Compliance & security

Self-hosted SBOM generation for Java, JavaScript, Python, and Go

Produce a CycloneDX software bill of materials for your Maven, Gradle, npm, Python, or Go project on your own infrastructure. One lightweight container — your source code and the resulting SBOM never touch a vendor cloud.

Generate your first SBOM → Responding to an SBOM request?

Answering an SBOM request shouldn’t create a new risk

SBOM requests almost always come from a security or vendor-risk team worried about third-party data exposure. Answering one by piping your source through a SaaS scanner is self-defeating: you become a new subprocessor your customer then has to vet, and your code leaves your control to produce a document about controlling it. For regulated, defense, finance, and data-residency-bound teams, that trade is a non-starter.

depproof removes the trade. It’s self-hosted by default — a single container with nothing to install and nothing left running. It scans and exits, leaving the SBOM and report behind, on your infrastructure.

What you run, and what you get

# pull the scanner into your own registry / host
docker pull ghcr.io/depproof/depproof:v0

# generate a CycloneDX SBOM for a Maven project — no build, self-hosted
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan --discover --root /work --html --output-dir /work
  • A CycloneDX SBOM — components, the resolved dependency graph, SPDX license identifiers, and vulnerability ratings.
  • A self-contained HTML report — no external fonts, CDN, or JS; safe to archive as evidence.
  • Full transitive coverage — the SBOM reflects the whole dependency tree, not just your direct dependencies.
  • OSV.dev advisory data — open, portable vulnerability data, not a proprietary database that locks in your findings.

Running in a locked-down network

depproof runs on your own infrastructure, but it isn’t zero-network by default — it resolves dependencies against Maven Central and pulls advisories from OSV.dev. In a locked-down environment you make two standard adjustments:

  • Point it at your internal Maven mirror (Nexus, Artifactory) exactly as any Maven build resolves through it — depproof reads your existing Maven settings, so your mirror just works.
  • Allowlist api.osv.dev for advisory data, or run the audit for its license and inventory value where outbound access isn’t available.

Either way, your source code and the generated SBOM never leave your infrastructure — there is no depproof cloud to send anything to.

Where self-hosted generation matters most

The teams that feel this hardest share one trait: their code can’t leave, but the SBOM requests keep coming.

  • Defense & government contractors — ITAR/CUI and classified networks where source can’t touch a commercial cloud, yet SBOMs are increasingly a contract requirement.
  • Financial services — data-residency and third-party-risk rules that turn every new SaaS subprocessor into a formal review.
  • Healthcare & medical devices — HIPAA constraints and FDA supplier expectations, with an SBOM now part of premarket submissions.
  • Any vendor under review — when a customer’s security questionnaire asks for an SBOM and asks how many subprocessors you use, generating it in-house answers both at once.

For all of them, a self-hosted generator turns “produce an SBOM” from a data-governance problem into a one-command build step — the SBOM is the only thing that leaves, and only to the customer who asked for it.

Honest scope

depproof covers your JVM (Maven and Gradle), JavaScript/Node (npm, pnpm, yarn, bun), Python (PyPI) and Go (modules) dependencies. Maven resolves fully from source with no build; npm and Python resolve from the lockfile with no install; Go resolves from its module graph; Gradle is scanned after your build (see the docs). It generates your SBOM from your codebase — it isn’t a tool for ingesting and scoring a third party’s SBOM file. If your product also ships Go or container images, generate those SBOMs with the right tool for each and combine them. And an SBOM is an inventory: signed attestations and VEX are separate artifacts — provide them only if you truly produce them.

FAQ

Does it work in an air-gapped or locked-down network?

depproof runs on your own infrastructure, but it isn’t zero-network by default: it resolves dependencies against Maven Central and pulls advisory data from OSV.dev. In a locked-down environment, point it at your internal Maven mirror (Nexus/Artifactory) the way any Maven build would, and allowlist api.osv.dev for vulnerability data. Your source code and the resulting SBOM never leave your infrastructure either way.

What format is the SBOM?

CycloneDX JSON, with the component list, the resolved dependency graph, license identifiers, and vulnerability ratings — the machine-readable artifact procurement and vendor-risk teams ask for.

Which ecosystems does it cover?

Four ecosystems today: the JVM (Maven and Gradle), JavaScript/Node (npm, pnpm, yarn, and bun), Python (PyPI), and Go (modules). Maven resolves fully from source with no build; npm and Python resolve from the lockfile with no install; Go resolves from its module graph; Gradle is scanned after your build. If your product also ships container layers, generate those SBOMs with the right tool for each.

Generate your first SBOM → 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.