ci: declare contents:read on detect-breaking-changes workflow#666
Closed
arpitjain099 wants to merge 1 commit into
Closed
ci: declare contents:read on detect-breaking-changes workflow#666arpitjain099 wants to merge 1 commit into
arpitjain099 wants to merge 1 commit into
Conversation
The detect_breaking_changes job only checks out the PR head with enough depth to reach the PR base, sets up Go, and runs ./scripts/detect-breaking-changes against the base SHA. No GitHub API write, no cache. contents:read is the floor. Matches the per-job permissions block already in ci.yml (contents:read + id-token:write for the stainless-sdks variant). Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Author
|
Sorry, duplicate of #665 which I opened earlier today and forgot about. Closing. |
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
1 participant
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.
The
detect_breaking_changesjob currently inherits the repo default token scope. It only runsactions/checkout(withfetch-depth: commits + 1so it can reach the PR base),actions/setup-go, and./scripts/detect-breaking-changesagainst the base SHA. No GitHub API write, no comment-on-PR, no registry push.Worth declaring even if the repo-default is already read: the in-file block survives any future change to the Settings > Actions > General token-permissions toggle, and the OpenSSF Scorecard Token-Permissions check counts only per-workflow declarations (the implicit default doesn't move the score).
The defense-in-depth motivation is the CVE-2025-30066 shape: a compromised third-party action (
actions/setup-goin this case) runs inside the existing job context and exfiltrates theGITHUB_TOKENvia build logs. The blast radius equals the token's scope at issue time; pinning the workflow tocontents: readbounds it independent of what a YAML author with repo-write access could have done (that's a different attack vector).Style matches the per-job permission block already declared in
ci.yml(contents: read+id-token: writefor the stainless-sdks variant).create-releases.ymlis intentionally left out of this PR because thestainless-api/trigger-release-pleasestep there needs broader scope.