Skip to main content
Generate an SBOM in CI, then check its licenses against your policy. The workflow below checks the saved document, so license enforcement needs no second upload. Scan is Alpha. Pin a released version and review migration notes before upgrading.

Prepare your repository

Before adding the workflow:
  1. Review what Scan uploads. Upload commands send the full contents of selected package files without redacting them.
  2. Save a reviewed inventory in githits-scan.toml and commit it.
  3. Enable a reviewed [licenses] policy in that configuration.
  4. Store an API token as the repository secret GITHITS_API_TOKEN.

GitHub Actions

Save this workflow as .github/workflows/dependencies.yml. It runs on pushes and manual dispatch, and installs version 0.3.0 from crates.io.
The generation step checks for inventory drift before uploading. The license step reads bom.cdx.json offline and needs no token. GitHub Actions uploads the SBOM artifact after both steps succeed. Review reports before sharing them. They can contain private package names and paths.

Add a dependency audit

Run githits-scan audit in a separate step with GITHITS_API_TOKEN supplied from the same secret. An audit checks vulnerabilities, deprecated releases, outdated and duplicate versions, and manifest/lockfile disagreements. Any finding or incomplete check returns exit 1. The audit submits another analysis job. It does not read the SBOM generated above.

Interpret failures

Do not mask exit 1 with || true when enforcing a check. If the inventory changes, review it before updating githits-scan.toml. Automatically running detect --save in CI would accept changes without that review. See the exit code reference and troubleshooting guide for details.

Protect tokens and uploads

Keep secrets out of untrusted fork jobs. Do not use pull_request_target to run untrusted code with a token. Keep shell tracing off and inject tokens into the steps that need them. Review uploaded data and exclusions before enabling a workflow. Do not automatically resubmit failed jobs in a retry loop. Each new submission can consume quota again. The HTTP API reference describes upload limits, quota, and job results.