GitHub/Repository Security/GitHub Workflows & Actions

From MozillaWiki
Jump to: navigation, search

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.

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. Please reach out to ### Learning about Workflow security issues

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
    • Note: While the action has 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.

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:

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)