Skip to content

GitHub Workflows security hardening #16075

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

Merged
merged 2 commits into from
Dec 13, 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.

@SethTisue
Copy link
Member

previously in this area: #15538

@sashashura
Copy link
Contributor Author

/signed cla

@sashashura
Copy link
Contributor Author

previously in this area: #15538

Looking at https://github.com/lampepfl/dotty/pull/15538/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR612 this added contents: write to the job that already had the permission when triggered on push, schedule or workflow_dispatch. This is not enough without defining top level read-only permission.

@sashashura
Copy link
Contributor Author

An example of current permissions (without the changes in the pull request):

image

@sashashura
Copy link
Contributor Author

Signed cla again...

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.

3 participants