Your first offline audit

This walks through producing an evidence bundle from a product directory, fully offline.

Fastest path: quickstart

quickstart auto-detects your project, scaffolds a minimal sbomflow.yaml with placeholders, runs an offline audit, and prints next steps:

bash
sbomflow quickstart .

Or use the guided, interactive setup (a real terminal only — see Interactive setup):

bash
sbomflow setup

Run a full audit

bash
sbomflow audit ./my-product \
  --output ./evidence \
  --product-name "My Gateway" \
  --product-version "1.0.0" \
  --product-class default

Important

--product-class records the manufacturer's declaration. SBOMFlow does not
classify your product; it records the class you declare (default,
important-class-i, important-class-ii, or critical).

This writes a directory of provenance-bearing artifacts, including evidence-pack.json, cyclonedx-sbom.json, spdx-sbom.json, cra-coverage.json, issues.json, release-gate.json, and a portable evidence-bundle.*. Add --as-of <ISO-8601> when you need byte-reproducible release artifacts from pinned inputs and run context. See Read an evidence bundle.

Offline vs. opt-in enrichment

Offline

By default the audit uses a clearly-labelled, non-real sample vulnerability
feed (identifiers begin with CVE-SAMPLE-). No data leaves your machine.

Network — opt-in

To match real advisories, enable a named lookup explicitly, e.g. --use-osv
(OSV), --use-nvd, --use-kev, --use-epss. These send component identifiers
(package URLs) to the named service — never your source or firmware. Real
firmware/OS-layer CVEs require a distro-tagged SBOM (pkg:deb / pkg:apk).

Exit codes

The audit uses stable exit codes. A 0 means the run completed or a gate was informational; a 1 means an enforced release gate blocked the run. Common input mistakes return 2 with a stable error code and a fix.

Next

Read an evidence bundle · Core concepts

SBOMFlow documentation. Engineering release-evidence support only — not a compliance or conformity claim, and not legal advice.