step-security/secure-workflows

Secure GitHub Actions CI/CD workflows via automated remediations

Secure Workflows

Secure GitHub Actions CI/CD workflows via automated remediations

Quickstart • Functionality • Contributing

Quickstart

Hosted Instance: app.stepsecurity.io/securerepo

To secure GitHub Actions workflows using a pull request:

• Go to https://app.stepsecurity.io/securerepo and enter your public GitHub repository
• Log in using your GitHub Account (no need to install any App or grant write access)
• View recommendations and click Create pull request. Here is an example pull request: electron/electron#36343.

Integration with OpenSSF Scorecard

• Add OpenSSF Scorecards starter workflow
• View the Scorecard results in GitHub Code Scanning UI
• Follow the remediation tip that points to https://app.stepsecurity.io

Self Hosted

To create an instance of Secure Workflows, deploy cloudformation/ecr.yml and cloudformation/resources.yml CloudFormation templates in your AWS account. You can take a look at .github/workflows/release.yml for reference.

Functionality

Secure Workflows

• Takes in a GitHub Actions workflow YAML file as an input
• Returns a transformed workflow file with fixes applied
• You can select which of these changes you want to make

1. Automatically set minimum GITHUB_TOKEN permissions

Why is this needed?

• The GITHUB_TOKEN is an automatically generated secret to make authenticated calls to the GitHub API
• If the token is compromised, it can be abused to compromise your environment (e.g., to overwrite releases or source code). This compromise will also impact everyone using your software in their supply chain.
• To limit the damage, GitHub recommends setting minimum token permissions for the GITHUB_TOKEN.

Before and After the fix

Pull request example: nginxinc/kubernetes-ingress#3134

In this pull request, minimum permissions are set automatically for the GITHUB_TOKEN

How does SecureWorkflows fix this issue?

• SecureWorkflows stores the permissions needed by different GitHub Actions in a knowledge base
• It looks up the permissions needed by each Action in your workflow and sums the permissions up to come up with a final recommendation
• If you are the owner of a GitHub Action, please contribute to the knowledge base

2. Pin Actions to a full length commit SHA

Why is this needed?

• GitHub Action tags and Docker tags are mutable, which poses a security risk
• If the tag changes you will not have a chance to review the change before it gets used
• GitHub's Security Hardening for GitHub Actions guide recommends pinning actions to full length commit for third party actions.

Before and After the fix

Before the fix, your workflow may look like this (use of v1 and latest tags)

After the fix, SecureWorkflows pins each Action and docker image to an immutable checksum.

Pull request example: electron/electron#36343

In this pull request, the workflow file has the GitHub Actions tags pinned automatically to their full-length commit SHA.

How does SecureWorkflows fix this issue?

• SecureWorkflows automates the process of getting the commit SHA for each mutable Action version or Docker image tag
• It does this by using GitHub and Docker registry APIs

3. Add Harden-Runner GitHub Action to each job

Why is this needed?

Harden-Runner GitHub Action installs a security agent on the Github-hosted runner to prevent exfiltration of credentials, monitor the build process, and detect compromised dependencies.

Before and After the fix

Pull request example: python-attrs/attrs#1034

This pull request adds the Harden Runner GitHub Action to the workflow file.

How does SecureWorkflows fix this issue?

SecureWorkflows updates the YAML file and adds Harden-Runner GitHub Action as the first step to each job.

4. Add or update Dependabot configuration

Why is this needed?

• You enable Dependabot version updates by checking a dependabot.yml configuration file into your repository
• Dependabot ensures that your repository automatically keeps up with the latest releases of the packages and applications it depends on

Before and After the fix

Before the fix, you might not have a dependabot.yml file or it might not cover all ecosystems used in your project.

After the fix, the dependabot.yml file is added or updated with configuration for all package ecosystems used in your project.

Pull request example: muir/libschema#31

This pull request updates the Dependabot configuration.

How does SecureWorkflows fix this issue?

SecureWorkflows updates the dependabot.yml file to add missing ecosystems. For example, if the Dependabot configuration updates npm packages but not GitHub Actions, it is updated to add the GitHub Actions ecosystem.

Contributing

Contributions are welcome!

If you are the owner of a GitHub Action, please contribute information about the use of GITHUB_TOKEN for your Action. This will enable the community to automatically calculate minimum token permissions for the GITHUB_TOKEN for their workflows. Check out the Contributing Guide