-
-
Notifications
You must be signed in to change notification settings - Fork 941
Have CodeQL scan GitHub Actions workflows as well as Python code #2032
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
So GitHub can regenerate a fresh new one based on current defaults.
This adds CodeQL scanning of GitHub Actions, while continuing to scan Python as well. This will subsequently be customized slightly to restore some elements of the preivous custom workflow that we may prefer.
This restores three aspects of the previous `codeql.yml`: - Run it on all branches, not just `main`. - Run it on the previous schedule rather than the new one, since there's no reason to change the schedule (though there's no reason to be attached to the old schedule either). - Use "CodeQL" rather than "CodeQL Advanced" as the workflow `name`, since this takes up less horizontal space when reading the reports from the checks. Of these, only the first is really significant.
This is another change back to the way we had it before, but the removals are based specifically on the guidance in the default workflow comments about why each permission was given by default.
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
I guess this comment was automatically posted because the approach I took was to delete the workflow in the first commit to let GitHub regenerate it. (Or maybe this comment is posted for all changes to the workflow now?) |
Three CI workflows that need only `contents: read` permissions and no other permissions did not have explicit permissions set, and would therefore be given permissions configured for the repository. It is recommended to set explicit workflow permissions. This does so, bringing those workflows inline with `pythonpackage.yml` (which had this), and closing three `actions/missing-workflow-permissions` CodeQL alerts (new since gitpython-developers#2032 enabled scanning of GHA workflows). See also: https://codeql.github.com/codeql-query-help/actions/actions-missing-workflow-permissions/
Three CI workflows that need only `contents: read` permissions and no other permissions did not have explicit permissions set, and would therefore be given default permissions configured for the repository, which might be more expansive than the workflows need. It is recommended to set explicit workflow permissions [1]. This does that, specifying permissions as `pythonpackage.yml` already did, and closing three `actions/missing-workflow-permissions` CodeQL alerts (new since gitpython-developers#2032 enabled scanning of GHA workflows). [1]: https://codeql.github.com/codeql-query-help/actions/actions-missing-workflow-permissions/
This regenerates the
codeq.yml
workflow to modernize it and to get current defaults, the most (or perhaps only) important one being to scan bothpython
andactions
, rather than onlypython
.Parts of the default that we deliberately deviate from, or that seem preferable to change based on the comments in the default workflow, are put back.
I've tested this in my fork, but I'll still wait for all CI to complete here before merging. Besides being a good usual practice, this also has a chance of catching permissions-related problems.