github
False positive: Workflow does not contain permissions
Description of the false positive
We get a lot of Workflow does not contain permissions alerts.
It's description states
If a GitHub Actions job or workflow has no explicit permissions set, then the repository permissions are used. Repositories created under organizations inherit the organization permissions. The organizations or repositories created before February 2023 have the default permissions set to read-write. Often these permissions do not adhere to the principle of least privilege and can be reduced to read-only, leaving the write permission only to a specific types as issues: write or pull-requests: write.
While our org was created before February 2023, the default permission on the org is set to read contents and packages only, and in the repository I can't even change the setting.
Code samples or links to source code
https://github.com/intility/templates/blob/8653a13809c06c5046e57cb689d8479726380414/.github/workflows/build-react.yml#L13-L36
URL to the alert on GitHub code scanning (optional)
https://github.com/intility/templates/security/code-scanning/4
The alert is raised based just on the Action YAML file, so it isn't privy to the actual org or repository configuration-- I'll raise feedback with the team that it would be desirable to restructure this check to use backend data to be more precise.
We have the same issue with the settings in the Git LFS project and organization, where we disabled all write permissions at the organization level after we tweaked our workflows so they only required read permissions, but subsequently received 12 CodeQL alerts regarding a lack of explicit permissions in the workflows.
If there's a way to make CodeQL aware of the actual permissions available to the workflows, that would be great!
I'm afraid this one is architecturally difficult -- CodeQL's execution environment doesn't have the rights to query these sorts of org-level attributes. Therefore I can't give a timescale here.
I'm afraid this one is architecturally difficult -- CodeQL's execution environment doesn't have the rights to query these sorts of org-level attributes. Therefore I can't give a timescale here.
Fair enough. In the interim, might it be possible to rephrase the message and/or the recommendation provided with the alerts? Perhaps it could more clearly state that the alert is based only on an analysis of the workflow YAML, and that the alert may not be an immediate concern if the repository or organization has explicitly disabled all write permissions.
I can appreciate that it's still a reasonable recommendation to suggest adding explicit read-only permissions to workflows, to protect against the case where a repository's or organization's settings are later made more permissive. However, these changes might not be something an administrator needs to tackle immediately if their current settings disallow all write access to workflows.
A thing we're also seeing is that because of this false-positive, someone who's not that experienced in actions trying to fix this might end up giving the actions more permissions than the action requires, and more than the default permissions.
Is there a way to disable this warning on an org-level?
@h3rmanj you might want to disable the query in this case: https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#excluding-specific-queries-from-analysis
Do I understand correctly that it would have to be configured on a per-repo basis?
Normally, yes, though there is also https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning-with-codeql-at-scale for CodeQL advanced setup across a group of repositories.
I've updated the qhelp at https://github.com/github/codeql/pull/20970 to (a) note the query can't account for repo and org settings, and (b) recommend why you might wish to list explicit permissions anyhow.
I've updated the qhelp at #20970 to (a) note the query can't account for repo and org settings, and (b) recommend why you might wish to list explicit permissions anyhow.
That's fantastic, thanks very much!