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.

[titanism]

This isn't useful for our CI; we don't publish anything, it just runs tests

[sashashura]

The issue is that you running the workflow with unrestricted permissions. A short time window is enough for a compromised dependency to compromise the repository. All these write permissions are not needed to run a CI.

[titanism]

How would it compromise the repository? Can you give a real example? Would it auto accept and merge an existing pull request?

[sashashura]

yarn install? npm build? Please note this is not about pull requests. They run with read-only permissions. However, the workflow starts on every push to the repository. Let's say a third party tool or dependency that the workflow installs and runs is compromised at a given moment. After a day or few hours NPM detects the malicious activity at takes it down. However the dependency may have run already on a legit push. The issue here is that the dependency has access to the privileged github token and can modify the commits, artifacts, etc.

[titanism]

This makes sense via process.env.GITHUB_TOKEN.