ci: add SBOM generation and artifact attestations to releases

[wizzomafizzo]

Summary

• Add Sigstore-signed build provenance attestations to release artifacts
• Generate SPDX SBOM and attach as both an attestation and a release asset
• Release artifacts verifiable with gh attestation verify

Summary by CodeRabbit

• Chores
  • Release artifacts now include Software Bill of Materials (SBOM) and build attestations, providing enhanced supply chain transparency and verification for downloads.

[coderabbitai]

📝 Walkthrough

Walkthrough

The workflow configuration expands job permissions and adds security artifact generation for tag-triggered releases. It now generates an SPDX JSON SBOM, creates build provenance and SBOM attestations using actions/attest, and uploads both the tarball(s) and SBOM file to the release.

Changes

Cohort / File(s)	Summary
Build Workflow Configuration .github/workflows/build.yaml	Expanded job permissions to include id-token: write and attestations: write. Added SBOM generation via cyclonedx-bom and creation of two attestations (build provenance and SBOM) for tag-triggered releases. Updated release step to upload both tarball and sbom.spdx.json.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• ci: harden workflows with pinned SHAs and explicit permissions #69: Both PRs modify the same .github/workflows/build.yaml workflow file—this PR expands permissions and adds SBOM generation with attestations, building upon earlier permission and configuration adjustments.

Poem

🐰 Hops of joy through the build pipeline swift,
Security seals with provenance gift,
SBOM attestations bloom, so fine,
Every artifact traced—a supply chain's sign! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding SBOM generation and artifact attestations to the CI/CD release process.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/attestations

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/build.yaml (1)

26-29: Scope elevated permissions to a release-only job.

Line 28 and Line 29 expand privileges for all build job executions. Consider moving attestation/release steps into a separate tag-only job so non-release runs don’t carry id-token: write and attestations: write.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build.yaml around lines 26 - 29, The build job currently
grants elevated permissions (id-token: write and attestations: write) under the
permissions block, which should be limited to release/tag runs; create a new job
(e.g., release or attest) that is triggered only on tag events and move the
id-token: write and attestations: write permissions and any attestation/release
steps into that job, while keeping the existing build job's permissions minimal
(remove id-token and attestations from build and leave only what it needs, e.g.,
contents: write or read) so non-release runs do not carry elevated privileges.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/build.yaml:
- Around line 26-29: The build job currently grants elevated permissions
(id-token: write and attestations: write) under the permissions block, which
should be limited to release/tag runs; create a new job (e.g., release or
attest) that is triggered only on tag events and move the id-token: write and
attestations: write permissions and any attestation/release steps into that job,
while keeping the existing build job's permissions minimal (remove id-token and
attestations from build and leave only what it needs, e.g., contents: write or
read) so non-release runs do not carry elevated privileges.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 29eef547-0ca1-4712-8f40-7e9b5a6d1d0d

📥 Commits

Reviewing files that changed from the base of the PR and between cd0cc78 and b9c1e43.

📒 Files selected for processing (1)

• .github/workflows/build.yaml