GitHub Actions Pipeline Hardening

Who it is for

A team with 5-50 GitHub Actions workflows written over the years by different people, using version tags, default write tokens and an AWS access key stored as a secret.

The problem

• Attacks such as the tj-actions/changed-files and trivy-action tag hijacks stole secrets from every pipeline that used a moving tag.
• Default tokens can write to the repository, and pull_request_target workflows can run untrusted code next to secrets.
• A long-lived cloud key in a secret turns a CI compromise into a cloud compromise.

What I do

• An audit that scores each workflow 0-100 against 16 rules and explains every finding in plain words.
• Pull request 1: SHA pins, permissions blocks, safe handling of untrusted input, timeouts, no persisted credentials.
• Pull request 2: stored AWS keys replaced by an OIDC role that only main, or a protected environment, can assume.
• CI gates (zizmor, actionlint, a pin check) and Dependabot with a cooldown, so it stays fixed.
• Optional add-on: a full-history secrets scan on a fresh clone (values never shown or tested) and an incident-exposure check against the tj-actions, reviewdog, Trivy and Checkmarx windows, turned into a rotation plan.

How it works

1. 1Read-only audit: a score per workflow
2. 2PR 1: pins, permissions, injection fixes
3. 3PR 2: OIDC role, no stored keys
4. 4CI gates and Dependabot cooldown
5. 5Before/after report

Day by day

1. Day 1I audit every workflow and read each one by hand to understand its intent (why a self-hosted runner, why pull_request_target).
2. Day 2Pull request 1, one commit per topic so you can review it step by step.
3. Day 3Pull request 2 for OIDC (Terraform module or console steps you apply), the CI gates, and the before/after report.

Evidence from the demo

The evidence below comes from my own demo project with synthetic data. It shows exactly what you receive; it is not a story about a client.

• Five realistic example workflows score 0/100 (F) before and 100/100 (A) after hardening.
• The kit audits itself in CI and fails below 90; findings appear in GitHub's Security tab as SARIF.
• The AWS login demo uses a role with zero permissions: it proves 'no stored keys' without any risk.
• `ghaudit exposure` checks today's workflows, the git history inside each incident window and the workflow runs in those windows; the kit runs it on itself in CI.

Demo project: GitHub Actions Hardening kit

Questions