sbom-verification.md

title	description	sidebar_position	author	ms.date	ms.topic	keywords	estimated_reading_time
SBOM Verification	Verify, download, and inspect the Software Bill of Materials published with each HVE Core release	3	Microsoft	2026-03-01	how-to	SBOM software bill of materials SPDX attestation Sigstore supply chain verification	5

Every HVE Core release publishes a Software Bill of Materials (SBOM) in SPDX 2.3 JSON format alongside the extension package. The SBOM lists every component bundled in the release, including names, versions, and licenses. Like build provenance, the SBOM is cryptographically attested using Sigstore so you can confirm it was generated by the official CI/CD pipeline.

What Gets Published

Each release produces two SBOM files:

File	Contents
hve-core-<version>.vsix.spdx.json	Components packaged inside the VSIX extension
dependencies.spdx.json	npm dependency tree used during the build

Both files are uploaded to the GitHub Release and attested with actions/attest. The per-extension SBOM is generated by anchore/sbom-action using the Syft scanner, which produces SPDX 2.3 JSON output.

Verifying the SBOM Attestation

SBOM attestation verification uses the GitHub CLI. Install it if you have not already:

# Windows (winget)
winget install GitHub.cli

# macOS (Homebrew)
brew install gh

Download the VSIX from a release (replace <version> with the release tag, e.g., v1.2.0):

gh release download <version> -R microsoft/hve-core -p '*.vsix'

Verify the SBOM attestation:

gh attestation verify hve-core-<version>.vsix -R microsoft/hve-core \
  --predicate-type https://spdx.dev/Document/v2.3

A successful verification confirms:

• The component inventory was generated from the official CI/CD pipeline
• The SBOM has not been modified since signing
• The SBOM corresponds to the verified VSIX artifact

Tip

Build provenance and SBOM are independent attestations. The default gh attestation verify command (without --predicate-type) verifies build provenance. Adding --predicate-type https://spdx.dev/Document/v2.3 verifies the SBOM instead.

Downloading and Inspecting

Download both SBOM files from a release:

gh release download <version> -R microsoft/hve-core -p '*.spdx.json'

Use jq to inspect the contents:

# Summary
jq '{
  version: .spdxVersion,
  name: .name,
  created: .creationInfo.created,
  packages: (.packages | length)
}' hve-core-<version>.vsix.spdx.json

# Package list with versions
jq '.packages[] | {name, versionInfo}' hve-core-<version>.vsix.spdx.json

# License information
jq '.packages[] | {name, licenseConcluded, licenseDeclared}' hve-core-<version>.vsix.spdx.json

Key SPDX Fields

The SBOM follows the SPDX 2.3 specification. These fields are most relevant for security and compliance review:

Field	Description
spdxVersion	Specification version (SPDX-2.3)
name	Document name identifying the scanned artifact
creationInfo	Timestamp and tool that generated the document
packages	Array of components with name, version, and supplier
licenseConcluded	License determined through analysis
licenseDeclared	License stated by the package author
relationships	Dependency graph between components

Consuming the SBOM

You can feed the SPDX JSON file into security and compliance tooling:

Use Case	Description
Vulnerability scanning	Import into tools like Grype, Trivy, or Dependabot to check for known CVEs in bundled components.
License compliance	Parse licenseConcluded and licenseDeclared fields to validate that all included licenses meet your organization's policy.
Inventory tracking	Use the package list to maintain an accurate record of third-party components in your environment.

Related Resources

• SECURITY.md: Build provenance verification and vulnerability reporting
• Threat Model: Security controls including SBOM attestation (SC-7)

---

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.