Guide · SBOM

Generate a CycloneDX SBOM for Maven — no build required

A software bill of materials (SBOM) is a machine-readable inventory of every component in your project. Here’s how to produce a CycloneDX SBOM for a Java/Maven project — the full transitive tree — with no build and no lockfile, in about five minutes.

Updated 22 Jul 2026 · by the depproof team

Why the standard approach makes you build first

The usual way to emit a CycloneDX SBOM from Maven is the cyclonedx-maven-plugin, which binds to a build lifecycle phase. To produce the SBOM it needs Maven to resolve — and often compile — the project first: the right JDK, network access to your repositories, and a green build. That’s fine in a healthy CI pipeline, but it’s a problem when you only have the source, a build is flaky for unrelated reasons, or you need an SBOM for code you received rather than code you own.

Everything an SBOM needs — the component list and the resolved dependency graph — is already determined by your POMs. You shouldn’t have to compile anything to get it.

Option 1 · GitHub Action

Add this to a workflow. depproof reads your POMs and covers the full transitive tree — no build, no lockfile — and uploads a CycloneDX SBOM (and an HTML report) as build artifacts. No mvn install in the job.

# .github/workflows/sbom.yml
name: sbom
on: [push]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depproof/depproof-action@v1
        with:
          fail-on: none  # report-only; just emit the SBOM

Option 2 · Docker container

The same scanner ships as one public image — run it in any CI, or locally. It scans and exits, leaving the SBOM behind.

docker pull ghcr.io/depproof/depproof:v0

# emit a CycloneDX SBOM for the current Maven project — no build
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan --discover --root /work --html --output-dir /work

What’s inside the SBOM

depproof emits CycloneDX JSON. Each SBOM includes:

Every component — direct and transitive — with its coordinates and version.
The resolved dependency graph, so consumers can see how each component was pulled in.
A clear license per component, named consistently so you can set policy on it.
Vulnerability ratings from OSV.dev — open, portable advisory data, not a proprietary database.

What about Gradle?

Maven POMs are declarative, so depproof resolves them with no build. Gradle build scripts are programs, so Gradle projects are scanned after your build — either way you get the same CycloneDX output. The docs show the exact Gradle setup.

Next steps

Generating the SBOM is usually a means to an end — answering a customer or auditor. Two common follow-ons:

Responding to a customer’s SBOM request — what to clarify and attach alongside the file.
Self-hosted SBOM generation — keeping the whole process on your own infrastructure, no SaaS.
Dependency governance — aggregating per-repo SBOMs into one org-wide, compliance-ready view.
The depproof hub — where those per-repo SBOMs become one cross-repo inventory you can search and monitor.
Scan Maven & Gradle for vulnerabilities — the CVE gate on the same no-build tree.

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