Module 12: Secure CI/CD Pipelines

Learning Objectives

• Identify CI/CD threat vectors
• Harden GitHub Actions workflows
• Implement pipeline isolation and secret scanning
• Deploy securely with signed artifacts and workload identity

Why This Matters

A compromised CI/CD pipeline is the fastest path from attacker to production. Securing the pipeline secures the entire delivery chain — from source code to running workload.

Lesson Content

CI/CD pipelines have privileged access to production systems. They pull source code, build artifacts, push to registries, and deploy to clusters. A compromised pipeline is a direct path to production compromise.

CI/CD Threat Vectors

• Poisoned pipeline execution: Malicious PR modifies workflow to exfiltrate secrets
• Dependency confusion: Attacker publishes a package with the same name as an internal one
• Leaked secrets: API keys printed in logs, exposed in artifacts, or committed to Git
• Unpinned actions: Third-party GitHub Actions updated with malicious code
• Over-permissioned runners: CI runners with cluster-admin access

Hardening GitHub Actions

# Secure GitHub Actions workflow
name: Secure Build
on:
  push:
    branches: [main]

permissions:
  contents: read        # Minimal! Not write
  packages: write       # Only for pushing images
  id-token: write       # For OIDC auth (no static secrets)

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4    # Pin to exact SHA in production
      - name: Secret Scan
        run: gitleaks detect --source . --verbose
      - name: Build
        run: docker build -t myapp .
      - name: Sign Image
        run: cosign sign ghcr.io/myorg/myapp:latest
      - name: Deploy via OIDC (no secrets!)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/deploy
          aws-region: us-east-1
          # No AWS_ACCESS_KEY_ID! OIDC temporary credentials only

Real-World Use Cases

• Hardening GitHub Actions for production deployments
• OIDC-based cloud authentication (zero static secrets)
• Secret scanning in pre-commit hooks
• Secure artifact signing in CI pipelines

Common Mistakes

• Using permissions: write-all in workflows
• Storing cloud credentials as repository secrets instead of OIDC
• Not scanning for leaked secrets before they reach the main branch
• Using unpinned action versions (uses: actions/checkout@main instead of SHA)

Production Story

A malicious PR modified a GitHub Actions workflow to exfiltrate repository secrets to an external server. The team had no workflow approval process and the PR was auto-merged. After adding branch protection, workflow approval, and OIDC auth, the attack vector was eliminated.

Career Relevance

CI/CD security is a growing specialization as DevSecOps becomes standard. Engineers who can harden pipelines are essential for any organization with continuous deployment.

Key Terms

OIDC

OpenID Connect — used for keyless authentication from CI to cloud

gitleaks

Tool for detecting hardcoded secrets in Git repositories

Branch Protection

GitHub rules requiring reviews, status checks, and signed commits

Pinned Actions

Referencing GitHub Actions by commit SHA instead of mutable tags

Hands-On Labs

1. Harden a GitHub Actions Workflow

   Apply security best practices to a CI/CD pipeline.

   30 min - Intermediate

   • Audit an insecure workflow (over-permissioned, unpinned actions)
   • Add minimal permissions, pin action versions to SHA
   • Add secret scanning with gitleaks
   • Configure OIDC for deployment (eliminate static secrets)

   View lab files on GitHub

2. Implement Secure Deployment Pipeline

   Build a pipeline that signs, scans, and deploys with verification.

   35 min - Advanced

   • Build and sign images with Cosign in CI
   • Generate SBOM and scan for CVEs
   • Configure admission controller to reject unsigned images
   • Deploy using OIDC workload identity (zero static secrets)

   View lab files on GitHub

Key Takeaways

• CI/CD pipelines are high-value targets — they have production access
• Use minimal permissions on every workflow — never write when read is enough
• Pin all third-party actions to specific commit SHAs
• Use OIDC for cloud authentication — eliminate all static secrets from CI
• Sign every artifact in CI, verify every artifact before deploying