Harden release workflow and GitHub Actions security #55
Description
Summary
Track the remaining release and GitHub Actions security work before the next public release.
Scope
This issue covers remaining hardening work only. It intentionally excludes any separate history-rewrite cleanup.
Proposed work
- Pin third-party GitHub Actions to full commit SHAs instead of mutable tags.
- Review release workflow dependencies and remove any unneeded third-party Actions.
- Prefer the smallest practical trust surface in release-sensitive jobs.
- Use a dedicated release signing subkey rather than a primary personal key.
- Store release-signing secrets in a protected GitHub Environment with approval gates.
- Keep GITHUB_TOKEN permissions as narrow as possible per job.
- Add protection around workflow changes, for example CODEOWNERS coverage for .github/workflows/.
- Add gitleaks to CI and document the corresponding local validation task.
- Consider publishing artifact attestations and documenting how consumers should verify release integrity.
- Long term: teach installer flows to verify the signed checksum file, not just the checksum contents.
Acceptance criteria
- Release-sensitive third-party Actions are pinned immutably or intentionally removed.
- Release signing uses a dedicated key/subkey path documented in the repo.
- Release secrets are scoped and protected appropriately.
- CI blocks new secret leaks.
- Workflow and environment protections are in place for release-sensitive changes.
References
- GitHub Actions security hardening:
https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/security-hardening-for-github-actions - GitHub secure use reference:
https://docs.github.com/actions/learn-github-actions/security-hardening-for-github-actions - GoReleaser signing:
https://goreleaser.com/customization/sign/