-
-
Notifications
You must be signed in to change notification settings - Fork 944
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
ci: workflows security hardening #1385
Conversation
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1385 +/- ##
==========================================
- Coverage 99.63% 99.62% -0.01%
==========================================
Files 2163 2163
Lines 241275 241275
Branches 1017 1013 -4
==========================================
- Hits 240392 240368 -24
- Misses 862 886 +24
Partials 21 21
|
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.
This PR seems legit, I haven't seen that many repositories that have the permissions explicitly set yet though.
A quick search in the js ecosystem didn't result in any explicit permission configurations (vite/vitest/...).
However, I only found a single PR for java (spring) by the same author.
Here is the GH-TOKEN permission diff:
Before: https://github.com/faker-js/faker/actions/runs/3107588269/jobs/5035863133#step:1:19
After: https://github.com/faker-js/faker/actions/runs/3115625100/jobs/5052991942#step:1:17
There are 19488 workflows already using explicit permissions. Though I don't know how many repositories it is. |
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.