GitHub Workflows security hardening

[sashashura]

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted.
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

[sashashura]

@timtebeek @mpkorstanje could you please review?

[sashashura]

An example of a recent workflow run with unrestricted permissions:

[mpkorstanje]

This doesn't look like the correct solution you are highlighting. Looking at How the permissions are calculated for a workflow job it appears we can limit the scope of the GITHUB_TOKEN for the organization by default and then only increase it for the specific workflow that need it.

The permissions for the GITHUB_TOKEN are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the Send write tokens to workflows from pull requests setting is not selected, the permissions are adjusted to change any write permissions to read only.

[sashashura]

It is one of the options. It is possible to switch defaults to read-only per org or repository level and I encourage you doing so. Just keep in mind that changing it per org may break the workflows that really need a subset of write permissions (issues: write to comment on issues or pull-requests: write to label pull requests, etc.). The decision of how to implement the policy: changing workflows one by one and making sure nothing is broken and then changing it for the whole org or just changing it on the org level and fixing what is needed is totally up to you.

[mpkorstanje]

Superseded by cucumber/common#2139