Conversation
CodeQL's actions/missing-workflow-permissions rule flags every job that leaves GITHUB_TOKEN at the repository default, so the CI workflow's two jobs produce an alert on main and a github-advanced-security review comment on any PR that touches the file. Both jobs only check out, build and test; neither pushes, comments or calls the API. A workflow-level contents:read covers them and closes the alert at its source.
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.
Closes the two open CodeQL alerts of rule
actions/missing-workflow-permissionsonmain(#1, #2), and stops thegithub-advanced-securitybot from leaving a review comment on every PR that touches the CI workflow.What the alert actually says
When a workflow declares no
permissions:block,GITHUB_TOKENis minted with the repository's default scopes. On older repos that default is read and write across contents, issues, pull requests, packages and more. Every step in the job — including third-party actions — can use that token. The rule's point is that a build-and-test job should not be handed a token that can push commits or publish packages.It is a hardening finding, not an exploited vulnerability. Nothing in this workflow misuses the token; the fix is to stop handing it out.
The change
A workflow-level block covering both jobs:
contents: readis all that is needed here —actions/checkoutreads the ref,setup-dotnet/setup-noderead nothing from the repo, and the remaining steps aredotnet build,dotnet test,npm ci,npm run lintandnpm run build. No step pushes, tags, comments or calls the API.release-prepare.ymlandrelease-publish.ymlalready declare their own (wider, and correctly so) permissions blocks and are untouched.Note for #103
#103 renames this file to
ci.yml, so it carries its own copy of the alert. Once that branch takes inmain, the rename carries this block across and the alert clears there too.