Skip to main content

Securing GitHub Actions and CI/CD Workflows

GitHub workflows and the actions they consist of are a powerful way to automate your CI/CD workflows as well as other repetitive tasks within your repository. Like any software system, these workflows must be secured to protect against vulnerabilities and malicious actors.

GitHub offers a number features to enhance the security of these workflows. In addition, following best practices, such as pinning actions to SHAs or limiting the number actions available within your organization can further enhance the security posture of your organization. However, managing these practices is complex and time-consuming at scale.

Minder addresses these challenges by enabling you to deploy security profiles that not only flag potential security issues related to the use of GitHub Actions but also provide options for automated remediation. By deploying a single security profile across your organization, Minder ensures that all enrolled repositories adhere to the same security baseline, automatically and at scale.

This tutorial will guide you through the different rules provided by Minder and show you how to deploy these profiles using Minder.

What is CI/CD security?

There are several aspects of improving the security posture of your GitHub workflows:

  • Limiting the selection of actions that are allowed to be used in your workflows
  • Limiting the permissions the actions have when interacting with your repositories
  • Ensuring the integrity of the actions to prevent attackers from injecting malicious code into your workflows by taking over a GitHub action

How Minder helps you secure your GitHub workflows

This section provides an overview of the rules that Minder ships to help you secure your GitHub workflows

  • Action workflows reference pinned tags (stacklok/actions_check_pinned_tags) - This rule ensures that all actions in your workflows are pinned to a SHA instead of a floating tag. Pinning an action to a tag ensures that you're running the code that the SHA is pointing to, so that even if a malicious actor takes over that third-party actions repo, pushes some malicious code, and then publishes the malicious action using an already-existing tag, you would still be using the non-malicious code that you originally pinned to. By default, the rule instance in the profile is configured to pin all actions except for slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml which doesn't work when pinned to a SHA. When a profile has "Automatic Remediations" enabled, Minder would open a pull request that pins the actions to the correct SHA without any manual intervention.
  • Workflow permissions - (stacklok/default_workflow_permissions) - This rule ensures that the default workflow permissions granted to GITHUB_TOKEN when running workflows in a repository are set to the expected value, as well as checks if GitHub Actions can submit approving pull request reviews. By default, the rule checks that the default permissions are set to read and that actions can not approve PRs.
  • Dependabot configured - (stacklok/dependabot_configured) - Ensures that Dependabot is configured to update the github-actions package ecosystem. When "Automatic Remediations" are enabled for this profile, minder would open a pull request with the appropriate Dependabot configuration.
  • stacklok/github_actions_allowed - Allows to restrict the actions that are allows to run in the registered repositories to all or a subset. What the subset should correspond to is then configured with the stacklok/allowed_selected_actions rule.
  • stacklok/allowed_selected_actions - When the stacklok/github_actions_allowed is set to only permit selected actions, this rule allows to further restrict the selection by allowing the actions that are permitted to run within registered repositories to those that are owned by GitHub or verified or match a pattern.
  • stacklok/repo_action_allow_list - Allows to configure a list of actions that are allowed to be present in the enrolled repositories. Note that this action doesn't have a remediation configured and is mostly useful to create an inventory of the actions that are used as it outputs the list of actions that are not in its allow list on failure.

Creating a new profile to secure GitHub Actions in Minder

Minder offers a precreated "GitHub Actions Workflow security" profile that you can deploy with a single click. This profile consists of these rules:

  • Action workflows reference pinned tags
  • Workflow permissions - (stacklok/default_workflow_permissions)
  • Dependabot configured - (stacklok/dependabot_configured) No further configuration of this profile after deployment is needed.

In addition, you can also add any of the rules listed above and create your custom profile and/or further customize it.

To create a new profile for your GitHub Workflofs, start by logging in to Minder and registering repositories.

To deploy the profile, navigate to "Profiles" and then select "New Profile". Select the "GitHub Actions Workflow security" profile and click "Apply". When the profile is created, Minder will display the newly created profile in the list of all profiles

Clicking on the "Profile Name" brings up the details of the new profile, including the list of rules the profile consists of.

View the profile results

To view any issues the profile might have found, navigate to a repository page and then select a name of any of the alerts. A detailed view of the finding will appear in a sidebar on the right.

Remediate the findings

By default, the profile that the wizard creates do not remediate automatically. To enable auto-remediation, navigate to the profile page and toggle the remediation settings to "on". That will trigger re-evaluation of the profile. In case one of the rules failed and Minder's rule had a remediation available, you might either see the evaluation failure disappear or Minder will open a pull request in your repository.