ci: add least-privilege permissions to GitHub Actions workflows#4157
ci: add least-privilege permissions to GitHub Actions workflows#4157peter-matkovski wants to merge 4 commits into
Conversation
Restrict default GITHUB_TOKEN scope per workflow. Write scopes granted only where jobs dispatch/cancel workflows, publish packages, or label issues/PRs. Refs: APPSEC-164
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis pull request adds explicit top-level ChangesWorkflow Permissions Hardening
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Nitpick comments (1)
.github/workflows/release-start.yml (1)
11-14: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value
actions: writemay be unused here —gh workflow runuses a custom PAT, not the default token.The "Integration Test" step overrides
GITHUB_TOKENwithsecrets.DANGER_GITHUB_API_TOKEN, so the default token'sactions: writescope isn't exercised by this call. Based on a retrieved learning, the repo's default GITHUB_TOKEN already includesactions: write, so this explicit grant may be unnecessary for the workflow's actual behavior — worth double-checking if any other step relies on the default token for actions-scoped calls.Based on learnings, "assume the default
GITHUB_TOKENpermissions already includeactions: write... Only add explicitpermissionsif the required scope is not covered by the repo's default token permissions."Also applies to: 33-36
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release-start.yml around lines 11 - 14, The workflow permissions in the release-start job appear to grant actions: write unnecessarily, since the Integration Test step uses secrets.DANGER_GITHUB_API_TOKEN instead of the default GITHUB_TOKEN. Review the release-start workflow and remove the explicit actions: write permission unless another step in the same workflow actually depends on the default token for actions-scoped calls, keeping only the permissions that are truly needed.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/record-snapshots.yml:
- Around line 6-9: The permissions block is malformed because actions: write is
indented under contents: read instead of being a sibling entry. Fix the YAML in
the workflow’s permissions section so Record Snapshots lists both contents and
actions at the same level, matching the intended scopes for the gh workflow run
call and keeping the workflow parseable.
In @.github/workflows/release-merge.yml:
- Around line 7-10: The workflow permissions block is malformed because issues:
read is indented under contents: read, which breaks YAML parsing. Fix the
permissions section in the release-merge workflow so both contents and issues
are sibling keys under permissions, and keep the indentation consistent with the
surrounding GitHub Actions YAML.
In @.github/workflows/release-start.yml:
- Around line 11-14: The workflow permissions block is misindented, causing
invalid YAML because actions: write is nested under contents: read. Fix the
permissions section so both permissions entries are aligned at the same level in
the release-start workflow, using the permissions mapping and its keys as the
unique markers to locate the issue.
In @.github/workflows/sdk-performance-metrics.yml:
- Around line 22-25: The permissions block in the workflow is malformed because
pull-requests is nested under contents instead of being a sibling entry, which
breaks YAML parsing. Fix the permissions section in the workflow file so that
permissions contains two sibling keys, contents and pull-requests, with their
read values aligned at the same level; use the permissions block near the
sdk-performance-metrics workflow definition to locate it.
In @.github/workflows/sdk-size-metrics.yml:
- Around line 19-22: The permissions block in the workflow YAML is malformed
because pull-requests: read is indented under contents: read instead of being a
sibling entry. Fix the permissions mapping in sdk-size-metrics by aligning
pull-requests with contents so the workflow parses correctly, and use the
existing permissions block in the workflow file as the place to update it.
In @.github/workflows/smoke-checks.yml:
- Around line 22-25: The permissions block in the smoke-checks workflow is
malformed because pull-requests: read is indented as if it were nested under
contents: read instead of being a sibling permission entry. Fix the YAML in the
permissions section so contents and pull-requests are aligned at the same level,
using the workflow’s permissions mapping to keep the file valid and parsable by
actionlint/YAMLlint.
In @.github/workflows/sonar.yml:
- Around line 12-15: The workflow permissions block has invalid YAML indentation
because pull-requests: read is nested under the scalar value for contents: read.
Fix the permissions section in the sonar workflow so contents and pull-requests
are sibling keys at the same indentation level, matching the valid pattern used
in the other workflow file.
In @.github/workflows/testflight.yml:
- Around line 25-28: The permissions block in the workflow YAML is malformed
because pull-requests: read is nested under contents: read instead of being a
sibling entry. Fix the permissions mapping in the testflight workflow so the
permissions section contains both contents and pull-requests at the same
indentation level; use the permissions block in the workflow file as the target
for the correction.
---
Nitpick comments:
In @.github/workflows/release-start.yml:
- Around line 11-14: The workflow permissions in the release-start job appear to
grant actions: write unnecessarily, since the Integration Test step uses
secrets.DANGER_GITHUB_API_TOKEN instead of the default GITHUB_TOKEN. Review the
release-start workflow and remove the explicit actions: write permission unless
another step in the same workflow actually depends on the default token for
actions-scoped calls, keeping only the permissions that are truly needed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 46076e67-35b5-43d4-a7de-6eba915c9119
📒 Files selected for processing (12)
.github/workflows/backend-checks.yml.github/workflows/cron-checks.yml.github/workflows/record-snapshots.yml.github/workflows/release-merge.yml.github/workflows/release-publish.yml.github/workflows/release-start.yml.github/workflows/sdk-performance-metrics.yml.github/workflows/sdk-size-metrics.yml.github/workflows/smoke-checks.yml.github/workflows/sonar.yml.github/workflows/testflight.yml.github/workflows/update-copyright.yml
Move workflow_dispatch back under on: in release-merge.yml and drop unnecessary actions: write from release-start.yml (gh workflow run uses DANGER_GITHUB_API_TOKEN). Co-authored-by: Cursor <cursoragent@cursor.com>
SDK Size
|
|



Summary
permissionsblocks for CodeQLactions/missing-workflow-permissionsalerts.actions: writewheregh workflow run/ cancel is used.Linear
Test plan
Summary by CodeRabbit