Get started

Two ways to run depproof.

Both produce the same output: a self-contained HTML report, a CycloneDX SBOM, and a pass/fail policy gate. Pick whichever fits where your builds already run.

1 · GitHub Action

Add depproof to any workflow. It resolves the full dependency tree, checks licenses and OSV advisories against your policy, and uploads the report + SBOM as build artifacts.

# .github/workflows/depproof.yml
name: depproof
on: [pull_request]

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

With no file or files input, the action discovers every manifest in the repo and emits a CycloneDX SBOM per manifest. Pin to a release (@v1.3.0) for reproducible runs, or track @v1 for the latest patch.

2 · Self-hosted container

The same scanner ships as one public image. Nothing to install and nothing left running — it runs and exits, leaving the report behind. Ideal for GitLab CI, Jenkins, or locked-down pipelines.

# pull the scanner
docker pull ghcr.io/depproof/depproof:v0

# audit the current project, write the report locally
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan --discover --root /work --fail-on high --html --output-dir /work

Gate on vulnerabilities

fail-on sets the vulnerability severity that fails a build — critical (default), high, medium, low, or none for a report-only run. Licenses are classified allowed, review, or forbidden in the report; automated CI gating on a license policy is on the roadmap.

Choosing a threshold is really a decision about what “clean” means — a short findings list isn’t proof there is nothing to find.

This page shows the shape of the workflow; the action README is the source of truth for exact inputs and the current release.