Skip to content

GitHub Workflows security hardening #3284

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 1 commit into from
Dec 11, 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.


Before submitting the PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

  • The commits are consistent with our contribution guidelines
  • [N/A] You've added tests (if possible) to cover your change(s)
  • All tests are passing (eldev test)
  • All code passes the linter (eldev lint) which is based on elisp-lint and includes
  • [N/A] You've updated the changelog (if adding/changing user-visible functionality)
  • [N/A] You've updated the user manual (if adding/changing user-visible functionality)

Thanks!

If you're just starting out to hack on CIDER you might find this section of its
manual
extremely useful.

@bbatsov bbatsov merged commit 228d2fe into clojure-emacs:master Dec 11, 2022
@bbatsov
Copy link
Member

bbatsov commented Dec 11, 2022

Thanks!

iarenaza added a commit to iarenaza/moodle-filter_multilang2 that referenced this pull request Aug 16, 2023
Copied from clojure-emacs/cider#3284

This commit adds explicit permissions section[1] to workflows. This is
a security best practice because by default workflows run with
extended set of permissions[2] (except from on: pull_request from
external forks[3]).

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[4] or compromised third party
tool or action) is restricted.  It is recommended to have most strict
permissions on the top level[5] and grant write permissions on job
level[6] case by case.

[1] https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
[2] https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
[3] https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
[4] https://securitylab.github.com/research/github-actions-untrusted-input/
[5] https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions
[6] https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
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.

2 participants