-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
Signed-off-by: Alex <aleksandrosansan@gmail.com>
This isn't useful for our CI; we don't publish anything, it just runs tests |
How would it compromise the repository? Can you give a real example? Would it auto accept and merge an existing pull request? |
|
This makes sense via |
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.