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 #3377
Conversation
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Hello, thank you for the PR. As you may have noticed this repo is configured to always require manual approval before any workflow runs, but I'd be happy to strengthen this further, especially as this could help improve the security of forks. The workflows require the ability to create releases and release artefacts, which I think means we'll also require the addition of |
Permissions are not as granular as they could be. |
But currently I set contents to read. Do I understand correctly that
creates GitHub release and needs the write permission? |
Yes, the prebuild step creates a release (if it doesn't already exist) with the same name as the tag and adds artefacts to that release. |
Add the contents: write for npx prebuild
Add the contents: write for npx prebuild
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update, one more question inline otherwise this is good to go.
Style consistency
Thank you! |
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.