When an auditor or a customer's security team asks "what is in your software, and how do you know?", a consistently produced SBOM is the cleanest possible answer. This guide explains how to use Vibgrate SBOMs as durable audit and compliance evidence. It is written for engineering leaders, security teams, and the developers who support them.
What compliance reviewers actually want
Most frameworks and questionnaires are looking for the same things:
- A current, accurate inventory of components.
- Evidence the inventory is produced repeatably, not assembled by hand once.
- The ability to retrieve the inventory for a specific released version.
- A link from components to licenses and known vulnerabilities.
An SBOM produced on every release, in a standard format, satisfies the first three directly; pairing it with vulnerability and license analysis covers the fourth.
Producing audit-ready SBOMs
Generate a standards-based SBOM as part of your release process:
vg sbom export --format cyclonedx --out sbom.cdx.json
For reviewers who standardize on SPDX, export that format as well:
vg sbom export --format spdx --out sbom.spdx.json
Exporting from the exact released tree ensures the evidence matches what shipped.
Naming and retention
Good evidence is findable later. A few practices help:
- Name files with the version, for example
sbom-2.3.0.cdx.json. - Retain SBOMs for as long as the corresponding version is supported.
- Store them where your audit trail lives — attached to releases, in artifact storage, or both.
Connecting to a broader audit trail
If your team uses Vibgrate Cloud, pushing scan results gives reviewers a dated, searchable history of scans and findings to complement the per-release SBOM files. Use vg push after authenticating, or vg scan --push to do both in one step. See the Vibgrate Cloud Upload documentation for setup.
Tips for a smoother audit
- Standardize on one primary format and produce a second only when a specific reviewer requires it.
- Keep the export step in CI so no release goes out without an SBOM.
- Document, in your release runbook, where SBOMs are stored — reviewers value the process as much as the artifact.
Related
- "Attach an SBOM to a Software Release" covers publishing.
- "License Findings and License Compliance" covers the legal dimension.
- See the Supply Chain Inventory documentation for governance.