Skip to content
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

GitHub Workflows security hardening #1756

Merged
merged 1 commit into from
Dec 8, 2022
Merged

Conversation

sashashura
Copy link
Contributor

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.

Signed-off-by: Alex <aleksandrosansan@gmail.com>
@titanism
Copy link
Collaborator

titanism commented Dec 8, 2022

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

@titanism titanism closed this Dec 8, 2022
@sashashura
Copy link
Contributor Author

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.
image

@titanism
Copy link
Collaborator

titanism commented Dec 8, 2022

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

@sashashura
Copy link
Contributor Author

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
Copy link
Collaborator

titanism commented Dec 8, 2022

This makes sense via process.env.GITHUB_TOKEN.

@titanism titanism reopened this Dec 8, 2022
@titanism titanism merged commit 3adc458 into ladjs:master Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants