ci(security): add explicit top-level permissions to two workflows#6285
ci(security): add explicit top-level permissions to two workflows#6285camgrimsec wants to merge 2 commits into
Conversation
… and pr-size Two workflows are missing a top-level 'permissions' block: - .github/workflows/docs-broken-links.yml - .github/workflows/pr-size.yml Without an explicit top-level block, GITHUB_TOKEN falls back to the repository default — which for repos created or migrated before the restricted default was rolled out can still be a permissive 'contents: write' across all unsetscoped jobs. Setting the top-level scope to read-only and letting individual jobs opt up (as pr-size already does with 'pull-requests: write' at job scope) follows the OpenSSF Scorecard 'Token-Permissions' recommendation and trims the blast radius if a third-party action gets compromised. Other workflows in this repo already follow this pattern (tests.yml, linter.yml, etc.) — this just aligns the two outliers.
![corridor-security[bot]](https://avatars.githubusercontent.com/in/1177339?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary: This PR adds explicit read-only top-level GitHub Actions permissions to two workflows, reducing the default GITHUB_TOKEN scope. No exploitable security vulnerabilities were identified.
Risk: Low risk. The changes are CI permission hardening only and do not introduce new authentication, authorization, data handling, or runtime attack surfaces.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughTwo GitHub Actions workflows ( ChangesWorkflow Permissions Hardening
🚥 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 |
1 participant
Two workflows are missing a top-level 'permissions' block:
Without an explicit top-level block, GITHUB_TOKEN falls back to the repository default.
Which for repos created or migrated before the restricted default was rolled out can still be a permissive 'contents: write' across all unsetscoped jobs.
Setting the top-level scope to read-only and letting individual jobs opt up (as pr-size already does with 'pull-requests: write' at job scope) follows the OpenSSF Scorecard 'Token-Permissions' recommendation and trims the blast radius if a third-party action gets compromised.
Other workflows in this repo already follow this pattern (tests.yml, linter.yml, etc.)
This just aligns the two outliers.
Summary by CodeRabbit
Note: These are internal infrastructure changes with no impact to end-user functionality.