Issue Description

Part of #256

Add SPDX SBOM generation and attestation to the existing attest-and-upload job in .github/workflows/main.yml. The SBOM is generated at the release commit, attested via Sigstore, and uploaded to the GitHub Release alongside the VSIX.

Implementation

Modify the attest-and-upload job to add three new steps after the VSIX artifact download:

1. Checkout code — actions/checkout with persist-credentials: false (needed for Syft workspace scan)
2. Generate SBOM — anchore/sbom-action@28d71544de8eaf1b958d335707167c5f783590ad (v0.22.2) scanning ./extension with format: spdx-json
3. Attest SBOM — actions/attest-sbom@bd218ad0dbcb3e146bd073d1d9c6d78e08aa8a0b (v2.4.0) attesting against the VSIX subject
4. Modify release upload — add dist/*.spdx.json to the gh release upload command

No new jobs, workflows, or permission changes required — the job already has id-token: write, attestations: write, and contents: write.

SBOM File Naming

hve-core-{version}.vsix.spdx.json

Following OpenSSF SBOM Everywhere SIG conventions.

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
• gh attestation verify works for both provenance and SBOM predicates
• All actions SHA-pinned per repository conventions

References

• anchore/sbom-action — Syft-based SBOM generator
• actions/attest-sbom — GitHub SBOM attestation action
• Research: Canonical SBOM Approach

How to Build This

This is a CI/CD implementation task using the task-implementor workflow.

Workflow: /task-research → /task-plan → /task-implement → /task-review

Phase 1: Research

Source Material

• This issue body
• #file:.github/workflows/main.yml (attest-and-upload job starting around line 150)
• #file:release-please-config.json (release configuration with draft: true)
• #file:.github/instructions/hve-core/workflows.instructions.md (workflow conventions)

Steps

1. Type /clear to start a fresh context.
2. Attach or open the files listed above.
3. Copy and run this prompt:

/task-research topic="SBOM generation and attestation in GitHub Actions release workflow"

Research how to add SBOM generation and attestation to the existing attest-and-upload job
in main.yml. Investigate:

1. The current attest-and-upload job structure (steps, permissions, artifact handling)
2. GitHub's anchore/sbom-action for SBOM generation (SPDX format, configuration options)
3. actions/attest-build-provenance integration with SBOM artifacts
4. SBOM file naming conventions (the issue specifies a pattern)
5. How draft releases interact with SBOM upload (the repo uses draft: true in release-please)
6. Required permissions for SBOM attestation (id-token: write, attestations: write)
7. How to upload SBOM as both a release asset and a build artifact

Output: Research document at .copilot-tracking/research/{{YYYY-MM-DD}}-sbom-attestation-research.md

Phase 2: Plan

Source Material

• Research document from Phase 1

Steps

1. Type /clear to start a fresh context.
2. Open the research document from Phase 1.
3. Copy and run this prompt:

/task-plan

Create an implementation plan for SBOM generation and attestation in the
attest-and-upload job. The plan should detail the new workflow steps, their order
relative to existing steps, permission requirements, and the SBOM file naming pattern.

Output: Plan at .copilot-tracking/plans/ and details at .copilot-tracking/details/

Phase 3: Implement

Source Material

• Plan from Phase 2

Steps

1. Type /clear to start a fresh context.
2. Open the plan document from Phase 2.
3. Copy and run this prompt:

/task-implement

Implement SBOM generation and attestation in the main.yml attest-and-upload job
following the plan. Add the SBOM generation step, attestation, and release asset
upload. Ensure all action references are SHA-pinned.

Output: Modified .github/workflows/main.yml, changes log at .copilot-tracking/changes/

Phase 4: Review

Source Material

• Plan from Phase 2
• Changes log from Phase 3

Steps

1. Type /clear to start a fresh context.
2. Open the plan and changes log.
3. Copy and run this prompt:

/task-review

Review the SBOM generation and attestation implementation. Run these validation commands:
- npm run lint:yaml (validate workflow YAML)
Verify that action references are SHA-pinned, permissions are minimally scoped at job level,
SBOM file naming matches the specified pattern, and the workflow handles both draft and
published release states correctly.

Output: Review log at .copilot-tracking/reviews/

After Review

• Pass: All criteria met. Create a PR referencing this issue.
• Iterate: Review found issues. Run /clear, return to Phase 3 with the review feedback.
• Escalate: Fundamental design issue discovered. Run /clear, return to Phase 1 to research the gap.

Authoring Standards

• Workflow changes follow .github/instructions/hve-core/workflows.instructions.md
• Action references use SHA pinning with version comments
• Job-level permissions follow least-privilege principle
• YAML formatting matches existing main.yml patterns

Success Criteria

• SBOM is generated in SPDX format during the release workflow
• SBOM artifact is attested with build provenance
• SBOM is uploaded as a release asset
• Action references are SHA-pinned with version comments
• Permissions are job-scoped at minimum required level
• npm run lint:yaml passes