Issue Description

Add Software Bill of Materials (SBOM) generation to the release workflow, attesting and uploading it alongside the VSIX artifact.

SBOMs document all components and dependencies bundled in a software artifact, supporting supply chain security, vulnerability management, OSSF Best Practices criteria, and compliance requirements (Executive Order 14028).

Approach

Based on canonical SBOM research, the implementation uses:

• Format: SPDX 2.3 JSON — Microsoft's organizational standard, GitHub's native dependency graph format, ISO/IEC 5962:2021
• Generator: anchore/sbom-action (Syft) — scans at the exact release commit; used in GitHub's own actions/attest-sbom README examples
• Attestation: actions/attest-sbom — Sigstore attestation, same flow as existing build provenance

Note: The original issue specified CycloneDX format and vsce generate-manifest. Research found that vsce generate-manifest is a code signing tool (not SBOM), CycloneDX is not GitHub's native format, and Microsoft's organizational standard is SPDX. See the research document for the full comparison.

Architecture

The entire SBOM pipeline fits in the existing attest-and-upload job in main.yml. No new jobs, workflows, or permission changes needed.

attest-and-upload job (modified):
  ├─ download VSIX artifact        (existing)
  ├─ checkout code                  (NEW)
  ├─ Generate SBOM                  (NEW — anchore/sbom-action)
  ├─ Attest SBOM                    (NEW — actions/attest-sbom)
  ├─ Attest build provenance        (existing)
  ├─ Upload assets to release       (existing, modified to include SBOM)
  └─ Publish release                (existing)

Task List

• feat(build): add SBOM generation, attestation, and release upload #455 — Add SBOM generation, attestation, and release upload (main.yml)
• docs(security): add SBOM verification instructions to SECURITY.md #454 — Document SBOM verification in SECURITY.md
• chore(security): add SBOM artifact retention policy #453 — Add SBOM artifact retention policy and verify SHA pinning

All three tasks are independent and can be completed in parallel.

Acceptance Criteria

• SPDX 2.3 JSON SBOM generated from extension/ at the release commit
• SBOM attested with Sigstore via actions/attest-sbom
• SBOM uploaded to GitHub Release as hve-core-{version}.vsix.spdx.json
• Existing build provenance attestation unaffected
• SECURITY.md updated with SBOM verification instructions
• All actions SHA-pinned per repository conventions

References

• Canonical SBOM Approach Research
• SPDX 2.3 Specification
• anchore/sbom-action
• actions/attest-sbom
• OSSF SBOM Guidance
• GitHub Artifact Attestations