release: sign and verify exact CycloneDX SBOM evidence

[seonghobae]

Intent

Complete the buyer-visible release-evidence gap in #46 by connecting the deterministic CycloneDX 1.7 foundation to the protected-main release path without granting publication or ref-writing authority to SBOM generation or attestation code.

Changes

• generate one deterministic CycloneDX 1.7 document for the accepted wheel and one for the accepted source distribution
• bind distributions and SBOMs into the complete sorted SHA256SUMS; keep PyPI inputs limited to wheel and sdist
• add a credential-separated attest-release-evidence job after exact immutable tag verification
• pin actions/attest v4 to commit 1e69f48acb82d1966a394da916b4c1698aa569d6
• sign each exact distribution with its corresponding SBOM predicate
• verify local Sigstore bundles against the repository, signer workflow, exact source SHA/ref, GitHub-hosted runner provenance, and https://cyclonedx.org/bom
• compare each verified predicate to the generated CycloneDX JSON before PyPI or GitHub Release publication
• preserve both bundles in checksummed GitHub Release evidence
• document online and air-gapped verification, failure recovery, threat boundaries, and APA 7th references
• update CHANGELOG.md and add executable release-contract tests

Permission rationale

The issue’s original least-privilege list predates the current actions/attest v4 permission contract. The pinned action’s official README now requires artifact-metadata: write in addition to id-token: write and attestations: write to create the artifact storage record. The attestation job therefore grants that current documented permission while retaining contents: read and denying contents, packages, and pull-request write authority.

Test-first evidence

The new contract was written before workflow implementation. Current local focused evidence:

• signed-SBOM contract: 4 passed
• existing SBOM foundation contract: passed
• release workflow parses as YAML
• modified test compiles

Repository CI remains authoritative for the complete Python 3.10–3.13 suite, production statement and branch coverage, docstrings, package acceptance, SAST, Security Scan, and exact-current-head evidence.

Release boundary

This PR does not create a tag, publish a package, create a GitHub Release, move protected refs, change the OpenCode/NVIDIA product agent, use COPILOT_GITHUB_TOKEN, or alter the centrally managed review-agent identity. The release workflow still runs only through manual dispatch from the exact current protected main head and fails closed when external PyPI Trusted Publisher or environment configuration is absent.

Closes #46.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 47 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b389c3c9-62fb-4026-8365-e0fcfd3e1e1a

📥 Commits

Reviewing files that changed from the base of the PR and between 7c4792c and 2b9b107.

📒 Files selected for processing (5)

• .github/workflows/release.yml
• CHANGELOG.md
• docs/release.md
• docs/sbom-release-evidence.md
• tests/test_release_sbom_attestation_contract.py

---

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

[seonghobae]

Closing this exact-head proposal (2b9b107e8b74a38d76862cd9116d5de8f827a6e4) because it conflicts with the repository's release trust boundary and is superseded by the prerequisite integration path.

The branch modifies the credential-bearing release workflow before PR #52 is integrated, invokes the non-attestable foundation generator that omits the serialNumber required by the pinned actions/attest CycloneDX detector, and currently fails the full Python matrix because its asserted predicate contract is not present in the workflow. More importantly, SBOM signing must be introduced through the independently reviewed organization-owned, immutable, credential-separated mechanism tracked in ContextualWisdomLab/.github#783, not through a branch-local product workflow that receives OIDC and attestation write identities.

Safe portions may be reintroduced only after #52 lands and the central reusable workflow can consume an independently verified exact protected-main artifact tree without executing caller-controlled source under signing credentials.