GitHub Actions Security: OIDC, Secrets & Hardening

GitHub Actions security focuses on protecting secrets, authenticating to cloud providers securely, limiting workflow permissions, and preventing supply chain attacks.

What You'll Learn

In this tutorial, you'll learn how to use Openid Connect for keyless cloud authentication, store and access encrypted secrets, apply the principle of Least Privilege to workflow permissions, and prevent common security vulnerabilities.

Why It Matters

CI/CD pipelines are a prime attack vector. A compromised workflow can exfiltrate secrets, deploy malicious code, or access cloud infrastructure. Static access keys in Repository secrets, overly broad permissions, and third-party actions without review are common vulnerabilities that attackers exploit.

Real-World Use

Durga Antivirus Pro uses OIDC to authenticate to AWS from GitHub Actions without storing any AWS access keys. Workflow permissions are scoped to the minimum required actions. All third-party actions are pinned to specific commit SHAs and reviewed before use.

Openid Connect (OIDC)

OIDC eliminates static cloud credentials by exchanging a short-lived token:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

Configuring the AWS Role

Create an IAM role with a trust policy that allows GitHub Actions to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com]
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:myorg/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Secrets Management

Store secrets in GitHub and access them in workflows:

steps:
  - run: ./deploy.sh
    env:
      API_KEY: ${{ secrets.API_KEY }}

Best Practices

• Use environment-scoped secrets instead of Repository-wide secrets
• Rotate secrets regularly
• Never log or echo secret values
• Use OIDC instead of static keys where possible
• Audit secret access in GitHub audit logs

Minimum Permissions

Limit the default GITHUB_TOKEN scope:

jobs:
  test:
    permissions:
      contents: read
      issues: write
      pull-requests: none
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Third-Party Action Security

Pin actions to a specific commit SHA instead of a version tag:

steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Practice Questions

1. What problem does OIDC solve? It eliminates the need to store long-lived cloud credentials. Workflows authenticate using short-lived tokens tied to the specific workflow run.

2. How do you limit GITHUB_TOKEN permissions? Use the permissions key at the workflow or job level to specify exactly what the token can access.

3. Why should you pin actions to a commit SHA? Version tags are mutable and can be overwritten by the action maintainer or an attacker. A commit SHA is immutable.

4. What is the risk of echoing a secret in a workflow? Secrets echoed to logs are visible in the GitHub Actions UI and can be captured by anyone with access to the Repository.

5. Challenge: Configure an OIDC-based deployment workflow to AWS. Verify no static AWS keys are stored in the Repository.

Mini Project: Hardened Deployment Pipeline

Create a workflow that deploys to AWS using OIDC. Apply minimum permissions (read-only for code, write for id-token only). Pin all actions to commit SHAs. Use environment-scoped secrets for configuration values. Add a security audit step that checks for secret leaks in the output.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.