Add build provenance attestation verification

[Gajesh2007]

Summary

• Adds GitHub Sigstore-based build provenance attestation to the release workflow via actions/attest-build-provenance@v4
• Coordinator verifies attestations from the GitHub API before accepting release registrations, checking: source repo, workflow path, build trigger, runner environment, and actor
• Configurable via env vars (GITHUB_ATTESTATION_TOKEN, ATTESTATION_REQUIRED, TRUSTED_ACTORS) with soft mode (warnings) as default
• Optional gh attestation verify in install.sh for users with the GitHub CLI

Motivation

Currently, a leaked RELEASE_KEY alone is sufficient to register a malicious release with the coordinator. With this change, the coordinator independently verifies that the bundle was built by our GitHub Actions workflow, on GitHub-hosted runners, triggered by an authorized actor — even a compromised release key cannot bypass this.

Changes

File	What
.github/workflows/release.yml	Added id-token: write + attestations: write permissions, actions/attest-build-provenance@v4 step
coordinator/internal/buildattest/policy.go	Policy config loaded from env vars
coordinator/internal/buildattest/github.go	GitHub attestation REST API client
coordinator/internal/buildattest/verify.go	Sigstore bundle parsing, X.509 Fulcio OID extraction, policy enforcement
coordinator/internal/buildattest/verify_test.go	27 test cases covering valid/invalid bundles, policy enforcement, API mocking, edge cases
coordinator/internal/api/release_handlers.go	Attestation verification gate before accepting releases
coordinator/internal/api/server.go	Attestation policy field + setter
coordinator/cmd/coordinator/main.go	Wiring policy from env vars at startup
scripts/install.sh	Optional gh attestation verify (non-blocking)

Deployment

To enable, set on the coordinator:

GITHUB_ATTESTATION_TOKEN=ghp_...  # fine-grained PAT with attestations:read
ATTESTATION_REQUIRED=true          # optional: enforce (default: soft/warn mode)
TRUSTED_ACTORS=Gajesh2007          # optional: restrict release actors

Test plan

• 27 unit tests covering all verification paths (valid, wrong repo/workflow/trigger/runner/actor, malformed bundles, API errors)
• Full coordinator test suite passes (go test -race ./...)
• Builds with CGO_ENABLED=0 GOOS=linux GOARCH=amd64
• gofmt + go vet clean
• First real attestation will be created on next tag push — verify coordinator accepts it
• Test with ATTESTATION_REQUIRED=true in staging before production

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
d-inference	Ready	Preview	Apr 28, 2026 10:42pm
d-inference-console-ui-dev	Ready	Preview	Apr 28, 2026 10:42pm
d-inference-landing	Ready	Preview	Apr 28, 2026 10:42pm

[hankbobtheresearchoor]

Hermes Agent Review

Verdict: Minor suggestions

[WARNING]

• No cryptographic signature verification on DSSE envelopes: VerifyBundle extracts claims from the certificate and parses the DSSE envelope payload, but it does not verify the DSSE signature against the certificate public key. An attacker who can inject a fake attestation bundle could forge claims. The current implementation trusts that the GitHub API returns authentic bundles. Consider adding Sigstore signature verification for defense-in-depth.

• GitHub API rate limiting without retry/backoff: FetchAttestations returns an error on 429 but the caller does not retry. In production, the coordinator could exhaust the GitHub API rate limit and temporarily block all release registrations. Consider adding exponential backoff with retry for 429 responses.

• Policy hardcoded to a specific repo: The default TrustedRepo in PolicyFromEnv is hardcoded. While overridable via env var, any fork or alternate deployment must remember to set TRUSTED_REPO. Consider making it a required config parameter instead of relying on a default.

[SUGGESTION]

• Response body size limit is generous: The 10 MB limit on GitHub API response body is quite large for an attestation list. Consider a tighter limit (e.g., 1 MB) to reduce memory pressure.

• Log statement in VerifyRelease uses std log: The verified-release log line uses Go standard log.Printf instead of the structured logger used elsewhere. Consider using the structured logger for consistency.

• CertClaims could validate Issuer: The Issuer field is extracted but never validated against an expected OIDC issuer value. A malicious certificate from a different OIDC provider could pass policy checks if it has matching extensions. Consider adding an issuer allowlist validation step.

[LOOKS GOOD]

• Comprehensive test coverage: 20+ tests covering valid attestations, wrong repo/workflow/trigger/actor, self-hosted runners, malformed bundles, rate limiting, and edge cases.
• Policy-based enforcement with Required/Enabled split: The Required vs Enabled distinction is well-designed -- allowing soft enforcement during rollout and hard enforcement once confidence is established.
• Both V2 (DER) and legacy extension parsing: Backward-compatible claim extraction from Fulcio certificates is thorough.
• CI workflow attestation step: The attestation generation in the release workflow is correctly placed after the artifact is created, with proper permissions.
• Install script graceful degradation: Build provenance verification in the install script is optional and non-blocking -- correct for a gradual rollout.

Reviewed by Hermes Agent (hankbob)