Generate an SBOM in Your CI Pipeline

Producing an SBOM by hand once in a while is better than nothing, but the real value comes from generating one automatically on every build. This guide shows how to add SBOM export to a CI pipeline so each commit or release carries a fresh, reproducible inventory. It is aimed at developers and platform engineers maintaining CI.

Why automate it

A manually produced SBOM goes stale the moment a dependency changes. By generating it in CI you guarantee the SBOM always matches the exact dependency set that was built, and you create a durable record for every release.

The core step

Wherever your pipeline runs build steps, add an export step. The no-install form keeps the runner clean:

npx @vibgrate/cli sbom export --format cyclonedx --out sbom.cdx.json

If the CLI is already installed on the runner, use the binary directly:

vg sbom export --format cyclonedx --out sbom.cdx.json

Storing the artifact

After the export, save sbom.cdx.json as a build artifact so it is retrievable later. Each CI system has its own mechanism — for example, GitHub Actions uses actions/upload-artifact, GitLab CI uses the artifacts: keyword, and Azure Pipelines uses publish-artifact tasks. The Vibgrate command is the same across all of them.

Combining with a scan

Most teams already run a drift scan in CI. You can run both in the same job — the scan for your DriftScore and quality gates, and the SBOM export for supply-chain evidence:

npx @vibgrate/cli scan --fail-on error
npx @vibgrate/cli sbom export --format cyclonedx --out sbom.cdx.json

The scan can gate the build (failing on errors), while the SBOM export records what was built.

Pushing results to Vibgrate Cloud

If your team uses Vibgrate Cloud, you can push scan results so the dashboard tracks trends over time. Add --push to your scan, or run vg push after authenticating. See the Vibgrate Cloud Upload documentation for authentication via login or a DSN token.

Keeping it reproducible

• Always specify --format and --out explicitly so the output is deterministic.
• Pin or cache the CLI version where your pipeline allows, so the export behaves identically across runs.
• Run the export from the repository root so all lockfiles are in scope.

Troubleshooting

• Artifact missing? Confirm the export step ran before the upload-artifact step and wrote to the path you reference.
• Different results between runs? Ensure dependencies are installed deterministically (use lockfiles) before exporting.

Related

• "Attach an SBOM to a Software Release" covers release publishing.
• "Combine Drift Scoring and SBOM in One Workflow" goes deeper on running both together.
• See the CI Integration documentation for system-specific setup.