Add explicit least-privilege permissions to CI workflow#185
Merged
jdneo merged 2 commits intoMay 14, 2026
Conversation
Declare workflow-level contents: read as the default least-privilege scope, and override per-job to contents: write for the build job because maven-dependency-submission-action posts to the Dependency submission API and that endpoint requires contents: write. This documents the actual scope needed by each part of the workflow rather than inheriting the repository default token permissions, which is the recommended hardening pattern. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds explicit GitHub Actions token permissions to the CI workflow to document and constrain default GITHUB_TOKEN access.
Changes:
- Sets workflow-level default permissions to
contents: read. - Adds a
buildjob permission override tocontents: writefor dependency graph submission.
Member
|
The dependency graph keeps failing actually, maybe we can just remove that step and keep the permission to read |
Per @jdneo's review: the 'Update dependency graph' step (maven-dependency -submission-action) has been failing in CI; removing it lets the workflow hold to the strict workflow-level contents: read default with no per-job write override needed. Net change vs main: - workflow-level permissions: contents: read (new) - Update dependency graph step: removed - per-job permissions: contents: write override on build: not added Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Contributor
Author
|
Done @jdneo: dropped the |
9626e9e to
8cc2c11
Compare
jdneo
approved these changes
May 14, 2026
Member
|
Thank you for your contribution! |
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
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.
What
Adds explicit
permissions:declarations to.github/workflows/ci.yml:contents: readbuild:contents: writeWhy
ci.ymlcurrently does not declare anypermissions:block, soGITHUB_TOKENinherits the repository default token scope. The recommended hardening pattern from GitHub is to declare the minimum scope at the workflow level and override per-job only where a higher scope is actually needed.In this workflow:
checkout,setup-node,npm i,setup-java, maven build) only needcontents: read.Update dependency graphstep usesadvanced-security/maven-dependency-submission-action, which calls the Dependency submission API. That endpoint requirescontents: write.So the workflow-level default is
contents: readand thebuildjob overrides tocontents: writeto keep the dependency-graph upload working. Net effect: the security boundary is documented explicitly, and any future job added at the workflow level inherits the minimum scope by default.Verification
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/ci.yml'))"passes.Update dependency graphstep keeps thecontents: writescope it implicitly relied on via the repo default.Reference