ci: add explicit workflow-level permissions to swift - #157
Merged
bryankeller merged 1 commit intoMay 26, 2026
Conversation
Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
bryankeller
approved these changes
May 26, 2026
Contributor
|
Makes sense - thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds an explicit
permissions:block to the Swift CI build and test workflow so the GitHub-issued token for runs ofswift.ymlis granted only the scopes the job actually uses.The change is
permissions: contents: readat the top level. The workflow checks out the repo and runs its declared steps; there is nogit push, nogh release create, no comment-on-PR action, no API write.contents: readis therefore the minimum sufficient scope.Why bother for a workflow that looks innocuous: the worry is not what this workflow does today, it is what an action used inside it might be coerced into doing tomorrow if a third-party dependency in the action chain is compromised. The CVE-2025-30066 (tj-actions/changed-files, March 2025) incident is the canonical recent example. Without an explicit
permissions:block, the run inherits the repository-default token scope, which is permissive on many older repos.Aligns with GitHub's own token-hardening guidance and OpenSSF Scorecard (Token-Permissions). Standalone diff, no behavior change, YAML re-parses with
yaml.safe_load.