GitHub Workflows security hardening #1162
Conversation
Signed-off-by: Alex <aleksandrosansan@gmail.com>
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8e1855e:
|
Codecov Report
@@ Coverage Diff @@
## main #1162 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 4 4
Lines 181 181
Branches 36 36
=========================================
Hits 181 181
Flags with carried forward coverage won't be shown. Click here to find out more. 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| @@ -12,6 +12,10 @@ on: | |||
| - 'alpha' | |||
| - '!all-contributors/**' | |||
| pull_request: {} | |||
| permissions: | |||
| actions: write # to cancel/stop running workflows (styfle/cancel-workflow-action) | |||
There was a problem hiding this comment.
Could you include a summary of the permissions before and after for each change?
There was a problem hiding this comment.
Before the change for all jobs (as seen here https://github.com/testing-library/react-testing-library/actions/runs/3633193928/jobs/6129924592):
GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write
Deployments: write
Discussions: write
Issues: write
Metadata: read
Packages: write
Pages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
After the change
For the release job (not mention permissions are none):
GITHUB_TOKEN Permissions
Actions: write
Contents: write
Metadata: read
For all others:
GITHUB_TOKEN Permissions
Actions: write
Contents: read
Metadata: read
|
This was missing |
What:
This PR adds explicit permissions section to workflows.
Why:
This is a security best practice because by default workflows run with extended set of permissions (except from
on: pull_requestfrom 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.How:
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.
Checklist:
docs site N/A