vg sbom — Export, Compare & Attest SBOMs

Usage

# Export an SBOM
vg sbom export [--in <file>] [--format cyclonedx|spdx] [--out <file>]

# Compare two artifacts
vg sbom delta --from <file> --to <file> [--out <file>]

# Generate an OpenVEX document
vg sbom vex [--from <file>] [--statement <json>...] [--product <ref>] [--out <file>]

What It Does

The vg sbom command family treats SBOMs as operational intelligence rather than static compliance output.

sbom export

Emits a standards-based SBOM (CycloneDX or SPDX) from an existing scan artifact. This integrates with your organization's existing SBOM governance pipelines.

sbom delta

Compares dependencies between two scan artifacts and produces a diff: packages added, removed, changed, plus the drift score delta.

sbom vex

Generates a spec-compliant OpenVEX document (exploitability statements) ready to attach as a signed attestation. It is input-agnostic — it assembles a complete document from the statements you supply, so it works regardless of which scanner flagged the components. A zero-statement document is valid and honest: it asserts no known affected components.

Component identity

Match a component on its package URL (purl). That string is the primary identity in vg sbom export. vg scan --format json and .vibgrate/scan_result.json use the same coordinates and do not repeat the purl string.

These documents have no CPE field. The CLI does not write one, including when a name has several segments (a Maven group:artifact, an npm scope, a Go module path). A missing CPE is the normal record. Leave it missing. If a file from another cataloger carries a cpe property, keep the purl as the identity you match. A CPE does not replace a purl, rank above it, or stand in for a purl that was omitted (vibgrate:purlStatus unavailable).

Local advisory matching uses the same coordinates. vg scan --vulns --offline --package-manifest package-versions.json reads vulns under the ecosystem and the package name. Matches land on extended.vulnerabilities.packages[].

vg scan --vulns --offline --package-manifest package-versions.json --format json --out scan.json
vg sbom export --in scan.json --format cyclonedx --out sbom.cdx.json

For com.google.code.gson:gson at 2.11.0 in a Java project, key the join on pkg:maven/com.google.code.gson/[email protected] (CycloneDX purl and bom-ref), or on scan JSON type java / advisory ecosystem maven with package com.google.code.gson:gson and version 2.11.0. The group is the purl namespace. vg writes these fields in the two files above, not in one combined object.

Flags — export

Flags — delta

Flags — vex

Examples

Export CycloneDX SBOM

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

Export SPDX SBOM

vg sbom export --format spdx --out sbom.spdx.json

Compare two scans

vg sbom delta \
  --from .vibgrate/baseline.json \
  --to .vibgrate/scan_result.json \
  --out dependency-changes.json

Generate VEX and attest it to a signed image

vg sbom vex --product "$IMAGE_REF" \
  --statement '{"vulnerability":"CVE-2024-1","status":"not_affected","justification":"vulnerable_code_not_present"}' \
  --out openvex.json
cosign attest --yes --type openvex --predicate openvex.json "$IMAGE_REF"

Use Cases

• Compliance: Generate SBOMs required by procurement or regulatory teams
• Audit: Track which dependencies changed between releases
• Supply chain: Feed SBOM data into vulnerability management tools like Dependency-Track or Grype
• Change management: Use sbom delta to review dependency changes before merging large upgrade PRs
• Exploitability: Use sbom vex to publish OpenVEX attestations stating which CVEs actually affect your product