release: attach signed SBOM attestations to exact artifacts

[seonghobae]

Intent

Close issue #46 by integrating deterministic CycloneDX 1.7 SBOM evidence into the protected release path with credential-separated signing, exact attestation verification, offline bundles, and fail-closed publication ordering.

Test-first implementation

The initial contract commit fb7cc116edf22eff34ae087badfaa64e4a3eb39c failed before implementation. A follow-up contract also rejects cyclic release-job dependencies. The implemented path now requires:

• one deterministic SBOM for the canonical wheel and one for the canonical source distribution
• all four artifact/SBOM files bound by SHA256SUMS
• actions/attest v4.1.0 pinned to immutable commit 59d89421af93a897026c735860bf21b6eb4f7b26
• an OIDC signer with artifact/repository read, id-token: write, attestations: write, and artifact-metadata: write, but no checkout or repository-code execution
• one Sigstore bundle per exact artifact/SBOM pair
• a separate read-only hosted-runner verifier enforcing exact artifact digest, CycloneDX predicate type, repository, signer workflow, source commit, protected-main ref, and predicate equality
• PyPI and GitHub Release publication only after exact attestation verification
• checksummed verification reports and bundles attached to the public release
• online and controlled offline verification guidance using gh attestation trusted-root, --bundle, and --custom-trusted-root

Trust boundary

Build, immutable tag creation, attestation signing, read-only attestation verification, PyPI OIDC publication, and GitHub Release publication use separate jobs and least-privilege identities. The signer does not execute repository code. The PyPI job receives only canonical wheel/sdist files and contains no shell step. Public release creation remains downstream of PyPI and independently verified attestation evidence.

Standards basis

• CycloneDX 1.7 / ECMA-424
• in-toto CycloneDX predicate https://cyclonedx.org/bom
• GitHub artifact-attestation and offline-verification guidance
• GitHub actions/attest 4.1.0 action contract
• SLSA v1.2, without claiming a Build level before every normative requirement is independently demonstrated

Verification status

Current exact head: a4cc9fb8a1fef5d1021beb793fd95b5561ebb975.

The first implementation CI run found and corrected one documentation-contract line-wrap regression. Exact-current-head CI, package acceptance, SAST, Security Scan, CodeRabbit status, and review threads remain authoritative. Pending, queued, cancelled, stale-head, or previous-head evidence is not success.

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: 7 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: 3253dfe9-7cbb-4351-9881-5a4622b55c04

📥 Commits

Reviewing files that changed from the base of the PR and between 7c4792c and 21dc124.

📒 Files selected for processing (4)

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

---

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

[seonghobae]

Closing this implementation because it violates the repository's documented release trust boundary and integration sequence. Issue #46 and ContextualWisdomLab/.github#783 require the organization-owned, independently reviewed reusable attestation workflow to be implemented and immutably pinned before EgressWeave adds a narrow caller; this PR instead embeds OIDC/attestation write permissions directly in the repository-local release workflow. It also invokes generate_release_sbom.py, whose deterministic CycloneDX output intentionally has no serialNumber, while the pinned actions/attest@59d89421af93a897026c735860bf21b6eb4f7b26 detector requires bomFormat, specVersion, and serialNumber for CycloneDX. PR #52 is the bounded credential-free compatibility slice. After .github#783 is merged, a new EgressWeave integration PR should call that immutable reusable workflow and consume the attestable exact-artifact evidence without executing caller source under signing credentials.