depproof

Guide · Java / JVM

Scan Java dependencies for vulnerabilities — Maven & Gradle, no build

Here’s how to find known CVEs across your whole Java dependency tree — direct and transitive — for Maven with no build and Gradle after yours, and fail the build on a severity you choose. Open advisory data, self-hosted, nothing sent to a SaaS.

Updated 27 Jul 2026 · by the depproof team

Why not the usual Java scanners?

The common free option matches your dependencies against advisory data by guessing identifiers (CPEs), which is noisy — false positives you triage by hand — and it leans on a vulnerability feed that now needs an API key and rate-limits you. Build-plugin scanners need a successful build and a resolved classpath before they can see the tree at all. SaaS scanners avoid the build but want your code in their cloud.

depproof resolves the real transitive tree — for Maven straight from source, no build — and screens every dependency against OSV.dev, open and portable advisory data, on your own infrastructure, returning a pass/fail you can gate a PR on.

Option 1 · GitHub Action

Add this to a workflow. depproof resolves the full dependency tree, checks it for known vulnerabilities, and fails the job when it finds one at or above your threshold — no build step for Maven. 

# .github/workflows/vuln-scan.yml
name: vuln-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depproof/depproof-action@v1
        with:
          fail-on: high  # critical | high | medium | low | none

Option 2 · Docker container

The same scanner ships as one public image — run it in any CI, or locally. It exits non-zero when it finds a vulnerability at or above your threshold, so it drops straight into a pipeline step. 

docker pull ghcr.io/depproof/depproof:v0

# scan a Maven project for vulnerabilities — no build
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan --discover --root /work --fail-on high --html --output-dir /work

Accurate because it resolves the real tree

A vulnerability scan is only as good as the dependency graph under it, and for the JVM that graph is where most tools are weakest — versions resolved differently than your build would, optional and provided scopes mishandled, ranges guessed. depproof resolves the complete transitive tree the way an ecosystem-native build would:

  • Maven — no build. POMs are declarative data, so depproof resolves the full tree from source, exactly as your build would, without running it.
  • Gradle — after your build. A build.gradle(.kts) is a program, so Gradle projects are scanned after your build resolves the graph (the docs show the setup).
  • The whole tree, not just direct deps. Most CVEs ride in on transitive dependencies you never named — those are exactly the ones a shallow scan misses.

Fail the build on the severity you choose

fail-on is the gate. Pick the bar that matches your risk appetite:

  • critical — fail only on the most severe (the default).
  • high — fail on high and critical (a common CI bar).
  • medium / low — tighten the threshold further.
  • none — report-only; never fails, findings still land in the artifacts.

What you get

  • Known CVEs across the whole tree — direct and transitive, each with its severity and the advisory behind it.
  • A pass/fail exit code your CI can gate on, at the threshold you set.
  • An HTML report and a CycloneDX SBOM — the vulnerabilities and the component inventory in one run.

What this covers — and what it doesn’t

Being precise, because security claims are easy to overstate:

  • Known vulnerabilities and known-malicious packages. depproof surfaces everything OSV records for your dependencies — open and portable data, no proprietary database to be locked into.
  • It’s only as broad as OSV. depproof relies on OSV’s recorded advisories — it doesn’t run its own behavioral analysis or reachability analysis (whether a vulnerable path is actually reached). Coverage tracks OSV’s.
  • It’s only as broad as the file you scan. This is the one that catches teams out, and it is true of every scanner: a Gradle build script declares intent, while a lockfile or a dependency-tree dump is the build’s own answer. Scanning the former can return a clean, confident result while missing most of the tree — why zero findings is not zero risk explains how to spot it.

Where this fits

Vulnerability scanning is one part of software composition analysis (SCA) — the others are license checking and the SBOM, all in the same run. From here:

Run your first scan → Read the docs More guides

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. Product names are used nominatively.