secure-repo

secure-repo copied to clipboard

Secure GitHub Actions CI/CD workflows via automated remediations

Quickstart • Impact • Functionality Overview • 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
• Login using your GitHub Account (no need to install any App or grant write access)
• View recommendations and click Create pull request. Here is a sample pull request.

Integration with OpenSSF Scorecard

• Add OpenSSF Scorecards starter workflow
• View the Scorecard results in GitHub Code Scanning UI
• Follow 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.

Impact

• SecureWorkflows has been used to secure 30 of the top 100 critical open source projects
• SecureWorkflows was demoed at SupplyChainSecurityCon at Open Source Summit North America 2022

Functionality Overview

SecureWorkflows API

• 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 will also impact everyone who use your software in their software supply chain.
• To limit the damage, GitHub recommends setting minimum token permissions for the GITHUB_TOKEN.

Before and After the fix

Before the fix, your workflow may look like this (no permissions set)

jobs:
  closeissue:
    runs-on: ubuntu-latest

    steps:
      - name: Close Issue
        uses: peter-evans/close-issue@v1
        with:
          issue-number: 1
          comment: Auto-closing issue

After the fix, the workflow will have minimum permissions added for the GITHUB token.

permissions:
  contents: read

jobs:
  closeissue:
    permissions:
      issues: write # for peter-evans/close-issue to close issues
    runs-on: ubuntu-latest

    steps:
      - name: Close Issue
        uses: peter-evans/close-issue@v1
        with:
          issue-number: 1
          comment: Auto-closing issue

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 mutatble. This 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)

jobs:
  integration-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Integration test
        uses: docker://ghcr.io/step-security/integration-test/int:latest

After the fix, each Action and docker image will be pinned to an immutable checksum.

jobs:
  integration-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@544eadc6bf3d226fd7a7a9f0dc5b5bf7ca0675b9
      - name: Integration test
        uses: docker://ghcr.io/step-security/integration-test/int@sha256:1efef3bbdd297d1b321b9b4559092d3131961913bc68b7c92b681b4783d563f0

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

Before the fix, your workflow may look like this

jobs:
  closeissue:
    runs-on: ubuntu-latest

    steps:
      - name: Close Issue
        uses: peter-evans/close-issue@v1
        with:
          issue-number: 1
          comment: Auto-closing issue

After the fix, each workflow has the harden-runner Action added as the first step.

jobs:
  closeissue:
    runs-on: ubuntu-latest

    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@v1
        with:
          egress-policy: audit

      - name: Close Issue
        uses: peter-evans/close-issue@v1
        with:
          issue-number: 1
          comment: Auto-closing issue

How does SecureWorkflows fix this issue?

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

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