SBOM and OpenVEX Evidence From One Command

Two requests show up in every enterprise procurement and every audit. First: give us a bill of materials — the full list of what your software is built from. Second: tell us which of the vulnerabilities in those components actually affect your product, and prove it. Done by hand, both are slow, and both are stale the day after you export them.

vg sbom produces both from the scan you already ran, deterministically and offline.

SBOM: the parts list for your software

A Software Bill of Materials, or SBOM, is the inventory of every component your build includes — direct and transitive — with versions and licenses. It is the foundation of supply-chain evidence: you cannot reason about risk in software whose contents you cannot enumerate.

vg sbom export writes one in the two formats the industry actually asks for — CycloneDX and SPDX:

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

The output is deterministic: the same input produces byte-identical output, down to a stable document identifier. That matters more than it sounds — a bill of materials that changes on every run can't be diffed, cached, or signed with confidence.

vg sbom vex: say what's actually exploitable

An SBOM lists components; it does not say whether a given vulnerability in a component actually affects you. That is what VEX — a Vulnerability Exploitability eXchange document — is for. It lets you state, per vulnerability, "not affected, because the vulnerable code path is never reached" — turning a scary raw CVE list into an assessed one.

vg sbom vex generates a spec-compliant OpenVEX document:

$ vg sbom vex --from scan_result.json --out vex.json
✔ Wrote OpenVEX document (3 statements)

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "Vibgrate",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-0001" },
      "products": [{ "@id": "pkg:npm/lodash@4.17.19" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

Every statement carries one of the OpenVEX statuses — not_affected, affected, fixed, or under_investigation — and a not_affected status must give a justification from the spec's fixed set. Vibgrate validates the document as it builds it, so you never ship a VEX that a downstream tool will reject.

vg sbom delta: what changed since last release

Auditors and security teams care less about the snapshot than the change. vg sbom delta compares two bills of materials and reports exactly what was added, removed, or version-bumped between them:

$ vg sbom delta --from sbom.prev.json --to sbom.cdx.json

That is your release-over-release supply-chain diff, ready to attach to a change record.

Reproducible enough to sign

Attestation — a signed, verifiable claim about an artifact — only works if the artifact is reproducible. Because vg sbom output is deterministic, and vg sbom vex accepts an explicit --timestamp for byte-stable documents, you can generate the same evidence in CI and locally and get identical bytes to sign. And all of it runs offline: no component data leaves your machine to produce it.

Try it

$ vg scan
$ vg sbom export --format cyclonedx
$ vg sbom vex --from scan_result.json

The vg sbom reference documents every subcommand and flag, and the supply-chain guide shows how SBOM, VEX, and vulnerability attribution combine into a single evidence trail.