Improve security of GitHub Actions workflows

GitHub Actions Security

Specific version tags When using third-party actions, pin the version with a commit hash rather than a tag to shield your workflow from potential supply-chain compromise, since tags can be adjusted to a malicious codebase state but commit hashes provide immutability. This can be done by going to the codebase for the specific tag version and looking for the latest commit of the version desired and copying the commit’s full SHA from the url link. Use: uses: someperson/post-issue@f054a8b5c1271c37293245628f1cae047eff08c9 Instead of: uses: someperson/post-issue@v7 Downside is that the updates must be done by updating the commit hash instead of it being done automatically through moving the tag to a new release. This can be solved by using tools like Dependabot or Renovatebot by adding a comment of the version used, enabling automated dependency updates. Tools like StepSecurity can also be used.

Minimally scoped credentials Every credential used in the workflow should have the minimum required permissions to execute the job. In particular, use the ‘permissions’ key to make sure the GITHUB_TOKEN is configured with the least privileges for each job. permissions can be restricted at the repo, workflow or job level. Environment variables, like ${{ secrets.GITHUB_TOKEN }}, should be limited by scope, and should be declared at the step level when possible.

Pull_request_target (must be used for write access if PR is from forked repo) Do not use actions/checkout with this as it can give write permission and secrets access to untrusted code. Any building step, script execution, or even action call could be used to compromise the entire repository. This can be fixed by adding code to ensure that the code being checked out belongs to the base branch, which would also be limiting since the code checked out is not up to date for the PR. This can be done using:

- uses: actions/checkout@v4
  with:
    ref: ${{ github.base_ref }}

Triggers workflows based on the latest commit of the pull request's base branch. Even if workflow files are modified or deleted on feature branches, workflows on the default branch aren't affected so you can prevent malicious code from being executed in CI without code review. Another solution that allows pull_request_target with actions/checkout used on the PR branch, is to add an additional step of running workflow only on approval by trusted users, such that the trusted user has to check the changes in the code from the PR to ensure there is no malicious code before running the workflow.

Untrusted input Don't directly reference values you do not control, such as echo “${{github.event.pull_request.title}}”, since it can contain malicious code and lead to an injection attack. Instead use an action with arguments (recommended):

uses: fakeaction/printtitle@v3 
with: 
title: ${{ github.event.pull_request.title }}

Or bind the value to an intermediate environment variable:

env: 
PR_TITLE: ${{ github.event.pull_request.title }}
run: | 
echo “$PR_TITLE”

Use OIDC and respective Secrets Manager for access to cloud providers instead of using secrets. Use GitHub Secrets to store keys securely and reference in workflows using ${{}}. Can use GitGuardian Shield to help with scanning for security vulnerabilities.

Refs: https://blog.gitguardian.com/github-actions-security-cheat-sheet/ https://dev.to/suzukishunsuke/secure-github-actions-by-pullrequesttarget-641

MarkBind / markbind

Improve security of GitHub Actions workflows #2488

Please confirm that you have searched existing issues in the repo

Any related issues?

What is the area that this feature belongs to?

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

GitHub Actions Security