CI/CD Pipeline Security & IaC Audit Playbook

Status: Draft — Samer's Field Audit Playbook
Curriculum synthesis derived from SANS SEC540 (Cloud Security and DevOps Automation).

Executive Objective

Under SOC 2 CC8 (Change Management), ISO 27001 A.8.25 (Secure Development Lifecycle), and DORA Article 24 (Resilience Testing), companies must prove that unauthorized changes or vulnerable dependencies cannot slip silently into production binaries.

This field manual walks through the exact commands and security gates to audit in a client's CI/CD workflow and Infrastructure as Code (IaC) repository.

Tooling Prerequisites

# 1. Checkov (Static code analysis for Terraform, CloudFormation, Kubernetes, ARM)
pip install checkov

# 2. Gitleaks (Fast secret detection in git history)
brew install gitleaks # or download binary from github.com/gitleaks/gitleaks

# 3. Semgrep (Custom AST code pattern security scanning)
pip install semgrep

# 4. Trivy (Container image and dependency vulnerability scanner)
brew install trivy

Step 1: Auditing Infrastructure as Code (Terraform) for Dangerous Defaults

Never rely on developers promising they don't open security groups to the world. Run an automated Checkov scan on their repo:

# Scan Terraform directory for high and critical compliance violations
checkov -d ./terraform --framework terraform --severity-threshold HIGH

# Focus scan specifically on SOC 2 and ISO 27001 benchmarks
checkov -d ./terraform --framework terraform --compliance SOC2,ISO27001

Key Red Flags to Look For:

Security groups with ingress 0.0.0.0/0 on ports 22 (SSH), 3389 (RDP), or database ports (5432, 3306).
Storage buckets with public-read or missing block_public_access configurations.
Unencrypted EBS volumes or database instances.

Step 2: Auditing Git History for Leaked Credentials (Gitleaks)

Committed API keys remain in git history even after a developer pushes a "delete secret" commit.

# Scan entire git commit tree history
gitleaks detect --source . --verbose --report-path gitleaks-audit-report.json

# Scan only the latest commit range in a pull request
gitleaks detect --source . --log-opts="origin/main..HEAD"

What to Do If a Secret Is Found:

Invalidate immediately: Treat the credential as actively compromised in public. Rotate the token at the provider (AWS, Stripe, GitHub).
Purge git history: Use git-filter-repo or BFG Repo-Cleaner to permanently scrub the blob from history.
Audit provider logs: Query CloudTrail / API access logs during the window between commit and rotation.

Step 3: Hardening GitHub Actions CI/CD Workflows

Inspect .github/workflows/*.yml files for the following critical supply chain anti-patterns:

1. Insecure Expression Injection

Ensure user-controlled pull request titles or branch names are not executed directly in shell blocks:

# ❌ VULNERABLE TO CODE INJECTION:
- run: echo "Branch name: ${{ github.head_ref }}"

# ✅ SECURE (Pass via environment variables):
- env:
    BRANCH_NAME: ${{ github.head_ref }}
  run: echo "Branch name: $BRANCH_NAME"

2. Pinned Commit Hashes for Third-Party Actions

Actions referenced by tag (e.g. @v3) can be compromised if an upstream author's account is hijacked. Enforce full 40-character commit SHAs:

# ❌ RISKY:
uses: actions/checkout@v4

# ✅ IMMUTABLE & VERIFIED:
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Step 4: Auditor Evidence Checklist (SOC 2 CC8 & ISO 27001 A.8.25)

Deliver this evidence package to external audit teams:

Mandatory Peer Reviews: Screenshot of GitHub repository Branch Protection rules showing Require pull request reviews before merging (minimum 2 approvals required).
Automated Status Checks: Evidence that Checkov/Gitleaks/Semgrep CI steps must exit 0 before the merge button turns green.
Production Separation: Evidence that developers do not have direct AWS production console write access; deployments only occur via signed CI/CD service roles.