Managing GitHub token permissions in CI/CD workflows

// GitHub Token Permissions Overview

In CI/CD processes, the GitHub token (GITHUB_TOKEN) is automatically generated for workflows. However, the default permissions assigned to this token can lead to overreach, granting more access than intended. By default, this token has write access to the repository, which might expose sensitive operations if misconfigured. Understanding how to minimize its permissions is crucial for maintaining a secure pipeline.

Adjusting Token Permissions

The permissions of GITHUB_TOKEN can be adjusted in the workflow file. This is done in the permissions key. A common mistake is leaving permissions at their default settings. For instance:

permissions:
  contents: read
  id-token: write

This configuration ensures that the token can only read repository contents, thereby limiting potential damage from a compromised workflow.

Consider SLSA Provenance

SLSA (Supply Chain Levels for Software Artifacts) provides a framework to ensure that software is built and deployed securely, enhancing the integrity of the CI/CD pipeline.

#### Implementing SLSA

To start with SLSA, ensure your workflow artifacts are verifiable. Use the SLSA level as a reference point to achieve a minimum level of assurance. Implement the following steps to establish provenance:

1. Build with a reproducible method: Ensure builds can be replayed from the same source inputs.

2. Store metadata: Capture and store information about the build environment and the build process. Use a logs repository to audit builds.

3. Sign artifacts: Signing generated artifacts is essential for verification.

4. Use GitHub's built-in support: Leverage GitHub Actions to automate this.

For instance, add metadata in your workflow:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Build
        run: |
          make build
          echo "commit: $(git rev-parse HEAD)" > build_info.txt

      - name: Upload artifact
        uses: actions/upload-artifact@v2
        with:
          name: my-artifact
          path: build_info.txt

Using Cosign for Signature Verification

Cosign is a tool that helps sign and verify container images. Using Cosign enhances artifact integrity and provides a means of ensuring only verified artifacts are deployed. Here’s how to integrate Cosign into your workflow:

1. Install Cosign if you haven’t done so:

   go install sigstore.dev/cosign/cmd/cosign@latest

2. Sign an artifact after building it:

   cosign sign --key cosign.key your-image:tag

3. Verify an artifact before deployment:

   cosign verify --key cosign.pub your-image:tag

This step ensures that only signed and verified images are used in production, reducing the risk of deploying malicious code.

Trade-offs and Failure Modes

While implementing stricter permissions and SLSA compliance increases security, it can also introduce complexity. Be aware of the following:

• Operational Overhead: More rigorous checks can slow down the deployment process, requiring teams to balance speed against security.

• False Positives: Stricter permissions may lead to legitimate builds failing due to insufficient access, necessitating appropriate logging and monitoring to catch these issues.

• Dependency Management: Relying on external libraries or tools for signing and verification introduces additional dependencies. Ensure you are familiar with their security practices.

Checklist for CI/CD Security

1. Review and restrict GITHUB_TOKEN permissions in workflows.

2. Implement SLSA practices for artifact verification.

3. Use Cosign for signing containers and other artifacts.

4. Regularly audit tokens and permissions in use.

5. Monitor build logs for any anomalies or failures.

6. Ensure all team members understand the implications of the changes made to the CI/CD pipeline.

7. Regularly review and update your security practices in accordance with new vulnerabilities and threats.

These steps create a more secure CI/CD process, thus reducing vulnerability exposure.

--- // FIELDOPS REPORT AUTHORIZED BY: Rachel H. //