Field Notes: Hardening Your CI/CD Pipeline

Your CI system has production credentials and runs arbitrary code from pull requests. Treat it like the crown jewels it is.

The five changes that matter most

1. Pin actions to a commit SHA, not a tag

2. Scope tokens to the minimum permissions

3. Never echo secrets, mask them

4. Require review on workflow file changes

5. Separate build and deploy credentials

Pinning to a SHA stops a compromised tag from becoming your problem:

jobs:
 build:
 permissions:
 contents: read # least privilege by default
 steps:
 - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
 - uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2
 with: { node-version: 20 }
 - run: npm ci && npm test

Verify, do not trust

Scan the pipeline itself. A quick gitleaks pass catches the obvious leaks before they ship:

# fail the build if a secret is committed
gitleaks detect --source . --redact --exit-code 1

# and audit third-party actions you depend on
gh api /repos/$ORG/$REPO/actions/permissions

A pipeline that can deploy can also be weaponized. Guard it accordingly.

Quick wins for this sprint

• Turn on required reviews for the default branch

• Rotate any token older than 90 days

• Enable secret scanning and push protection

Bottom line: most CI breaches are boring misconfigurations. Fix the boring things first.