ci: tighten GitHub Actions workflow security#1328
Conversation
Move `github.event.inputs.version` from inline expressions into step `env:` blocks so the value is interpolated by the shell rather than substituted into the shell command at workflow-rendering time. Addresses zizmor `template-injection` findings in the three packaging steps.
Pin all `uses:` references to immutable commit hashes (with the resolved tag as a trailing comment), so a compromise of an upstream tag cannot silently change what runs in CI. The pinned versions match what the floating tags currently resolve to, so no behaviour change is intended. Addresses zizmor `unpinned-uses` findings.
Set `persist-credentials: false` on every `actions/checkout` step so the GITHUB_TOKEN is not left available to subsequent steps after the checkout completes. None of the workflows push back to the repo, so no compensating change is needed. Addresses zizmor `artipacked` findings.
Add a top-level `permissions: contents: read` block to every workflow so the GITHUB_TOKEN is scoped down from the repo's default rather than relying on whatever the default happens to be. None of these workflows need to write back to the repo (no commits, comments, releases or package publishing happens here), so read-only is enough. Addresses zizmor `excessive-permissions` findings.
The reusable `ably/features/.github/workflows/sdk-features.yml` workflow declares one required secret (`ABLY_AWS_ACCOUNT_ID_SDK`) plus the auto-provided GITHUB_TOKEN, so there is no reason to forward every secret on this repo to it. Replace `secrets: inherit` with an explicit map containing just that secret. Addresses zizmor `secrets-inherit` finding.
Revert the SHA pin on `ably/features/.github/workflows/sdk-features.yml` back to `@main`. This workflow is the SDK feature-spec compliance suite — pinning it freezes the spec under test, which defeats the purpose of running it on every PR. The repo is org-owned and trusted, so the `unpinned-uses` finding is suppressed inline rather than fixed.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
WalkthroughSeven GitHub Actions workflows are updated to apply security hardening: restrict GitHub token permissions to read-only, pin actions to specific commit SHAs, disable credential persistence, replace secret inheritance with explicit passing, and use environment variables for build script parameters. ChangesGitHub Actions Security Hardening
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
VeskeR
left a comment
There was a problem hiding this comment.
Need to fix permissions sdk-features here and in other affected SDKs
| build: | ||
| uses: ably/features/.github/workflows/sdk-features.yml@main | ||
| # Track the live SDK feature spec on main rather than pinning. | ||
| uses: ably/features/.github/workflows/sdk-features.yml@main # zizmor: ignore[unpinned-uses] |
There was a problem hiding this comment.
sdk-features workflow requires permissions:
deployments: write
id-token: write
, but top level configured to only contents: read. This results in an invisible failure during workflow startup, and it's currently broken, see: https://github.com/ably/ably-dotnet/actions/runs/26446846130.
I can see the features workflow is now also broken for at least ably-js and ably-python since the related github actions hardening PRs have landed: ably-js, ably-python.
More SDK repos might be affected. Happy to review the fixes for them too.
Routine hardening of the workflows under
.github/workflows/based on a zizmor audit. No CI behaviour changes are intended - pinned action versions match what the floating tags currently resolve to, and the added permissions match what the workflows already do.Summary by CodeRabbit