GitHub Workflows and Actions

GitHub Workflows and Actions provide tremendous value, but also are subject to non-obvious abuse. They:

• are a “hybrid language”
• have non-obvious variable expansion semantics
• inherit (invisible) global state

As such, they take a bit of learning to utilize in a secure manner. The following steps are part of “best practices” for using GitHub Workflows, and are strongly recommended for all sensitive repos.

1. Protect all workflows by requiring code reviews from folks who have familiarized themselves with the security issues of workflows.
2. Use scanning to detect problems and lack of best practices.
3. Treat GitHub actions as you would any 3rd party library shipped with your product.
   • Examine the supply chain!
   • Use mitigations where appropriate.
4. As always, enforce “least privilege” wherever possible.
   • Explicitly set "persist-credentials: false" when using the "actions/checkout" action. (Prevent hidden state.)
   • Explicitly unset GITHUB_TOKEN when not needed at the workflow or job level with "permissions: {}".
5. When configuring automatic merging or making exceptions in the workflow for Dependabot, make sure to validate the user and not the actor in the Github action.
   • Use the check "github.event.pull_request.user.login == 'dependabot[bot]'" instead of "github.actor == 'dependabot[bot]'"

Resources and tools

There are a number of ways to implement the recommendations above. Here are some suggestions - other tools may be available and a better fit. (See requesting installations for more information.)

Learning about Workflow security issues

• Read GitHub’s security hardening for actions.
• Always reduce permissions to the minimum needed, using the permissions parameter. (more info)
• More details on how those vulnerabilities work, in a 3 part section from github:
  • Part 1 - Preventing Pwn requests
  • Part 2 - Sources of untrusted input
  • Part 3 - Understanding the GitHub Action Supply Chain
• Understand implications of running workflows on the pull_request_target event (read the Warning section).
• Real Life Misconfiguration examples (2024-07-02)
• Exploiting Dependabot (2024-08-06)
• Mitigating Attack Vectors in GitHub Workflows (2024-08-12)

Scanning Tools

• OSSF Scorecard action will detected unsafe workflows. Note that some findings are “stricter” than our recommendations. Please evaluate the benefit before adopting a “get to zero reported findings”. Recommendations:
  • Set publish_results to false. This is a manual step if you follow the installation instructions.
  • “Must correct” findings as of 2024-06-12 include
    • Dangerous Workflow
  • Note: While the ossf/scorecard-action (and its dependency step-security/harden-runner) been approved for use in all organizations, it may not yet have been added to an organization you are working in. If you receive a message that the action is not available, please follow these instructions to have it added.
• Synacktiv's octoscan, which can check workflows on all branches locally.

Supply Chain Hygiene

How much effort to put into supply chain checks for 3rd party actions is directly related to how much you can trust the providers. And that includes trusting the process of the providers to ensure that level of trust continues to be warranted over time.

Some indications that an action deserves some trust include:

• Does the author follow the Security Best Practices for authors of GitHub Actions?
• If the action is implemented via a container image, are there attestations about the image?

Unless you have some sort of contractual protection, you probably want to do the following for any action:

• Enforce least privilege – only provide a token that can do what the action should require to perform the advertised function.
• Harden the execution environment.
  • use tooling to block internet access, unless specifically needed
  • refactor jobs to minimize access to unneeded tokens, resources, and services
• Audit the code for reasonableness before first time use
  • Audit the changes before taking a version update
  • Don’t forget to audit dependencies
  • Consider permitting only a specific revision (instead of relying on a version tag)