depproof

Guide · Compliance & procurement

How to respond when a customer requires an SBOM

A security questionnaire or a new contract clause just asked you for a software bill of materials (SBOM). Here’s a practical way to answer it — what to clarify first, how to produce the SBOM and the license/vulnerability evidence behind it, and where to set honest boundaries.

Updated 18 Jul 2026 · by the depproof team · not legal advice

Why customers are suddenly asking

SBOM requests are moving from “nice to have” to a standard line item in vendor-risk reviews and procurement contracts, pushed by the EU Cyber Resilience Act and by US federal contract terms, which agencies may set at their own discretion since OMB rescinded the government-wide secure-software attestation mandate in January 2026. Your customer’s compliance team wants a machine-readable inventory of the open-source components in what they’re buying, plus a way to see the license and known-vulnerability risk that rides along with it.

Step 1 · Clarify what they actually want

“Send us your SBOM” hides several distinct questions. Pin these down before you generate anything:

  • Format — CycloneDX or SPDX? CycloneDX is the common default for security-driven requests.
  • Depth — direct dependencies only, or the full transitive tree? Almost always they mean the full tree, because that’s where the risk hides.
  • Scope of evidence — just the component inventory, or also license identifiers and known vulnerabilities?
  • Cadence — one-time, per-release, or on a schedule?

Step 2 · Generate the SBOM from your JVM code

depproof resolves your Maven/Gradle dependency tree, normalizes each license to an SPDX identifier, looks up vulnerabilities via OSV.dev, and emits a CycloneDX SBOM — as a GitHub Action or a single self-hosted container. 

# GitHub Action — produces a CycloneDX SBOM as a build artifact
- uses: depproof/depproof-action@v1
  with:
    fail-on: none  # report-only for an SBOM export

A note on accuracy so you don’t over-promise: Maven POMs are declarative, so depproof resolves the full tree with no build required. Gradle build scripts are programs, so Gradle projects are resolved after your build — the docs show the exact setup. Either way you get the same CycloneDX output.

Step 3 · Attach the license & vulnerability evidence

The SBOM is the inventory; the questions behind the request are usually “what’s the license exposure and what’s known-vulnerable?” depproof’s self-contained HTML report answers both alongside the SBOM: every dependency’s SPDX license and its OSV advisories, in one artifact you can hand to the reviewer or archive as evidence.

Why generating it on your own infrastructure matters here

There’s an irony in vendor-risk reviews: the request comes from a team worried about third-party data exposure. Piping your source code through a SaaS scanner to answer it can make you a new subprocessor your own customer then has to vet. depproof is self-hosted — it runs as one lightweight container on your own infrastructure, so your code and the resulting SBOM never leave your infrastructure and you add no third-party data path to the answer. That’s the wedge for regulated and security-conscious teams — see self-hosted SBOM generation.

Step 4 · Set honest scope — don’t over-commit

The fastest way to lose trust in a vendor review is to promise more than you produce. Be precise:

  • State the ecosystem covered. depproof covers your JVM (Maven/Gradle), JavaScript/Node (npm, pnpm, yarn, bun), Python (PyPI), and Go (modules) dependencies. If your product also ships container layers, generate those SBOMs with the right tool for each and say which is which.
  • Know which file each SBOM was built from. An SBOM is only as complete as its input — a lockfile yields the tree you ship, a manifest yields only what you declared. Before you send it, check the component count is in the range you expect and that transitive dependencies are actually present; the signatures of an incomplete scan take about five minutes to rule out, and are far cheaper to catch now than in a customer’s review.
  • Don’t claim a signed attestation or VEX you don’t have. An SBOM is an inventory; cryptographic attestation (Sigstore/Cosign) and VEX are separate artifacts. Provide them only if you truly do.
  • Describe how it’s derived. The SBOM reflects the resolved dependency graph from your build metadata — a strength (works pre-build for Maven, with no build step), stated plainly.
Generate your first SBOM → Read the docs More guides

depproof is free for open source and teams under $1M revenue — see pricing. This guide is general information, not legal advice; confirm your obligations with your own counsel. The action README is the source of truth for exact inputs and the current release.