Secure GitHub Actions CI/CD Pipeline Review

In March 2025 the tj-actions/changed-files action was compromised: the attacker dumped runner memory into build logs and repointed existing version tags at the malicious commit, so every workflow pinned to a mutable tag pulled poisoned code on its next run. Only the repositories that pinned to a full commit SHA were untouched. That’s the whole argument for taking CI/CD security seriously in one incident — the pipeline legitimately holds the credentials to production, so compromising it is faster than attacking production directly and comes pre-authorised to deploy.

This Secure GitHub Actions CI/CD Pipeline Review reads your workflows the way that attacker did, looking for the misconfigurations that let someone exfiltrate a secret, inject code into a build, or hijack a deployment. Then it hands back fixes your developers can actually merge — because a hardening recommendation that breaks every workflow gets reverted by Friday.

The Attack Vectors We Look For

GitHub Actions is genuinely powerful, and its defaults are tuned so a workflow works on the first try — which means tuned for convenience, not for containment. The five things attackers reach for:

Token Privileges Depending on org and repo settings, GITHUB_TOKEN can default to read and write across the repo. A workflow compromised through any other vector then inherits the ability to push code or tamper with releases. The fix is least privilege — read-only by default, write granted only to the specific job that needs it. The trade-off to expect: flipping the org default to read-only will break workflows that silently relied on write, so it’s staged, not flipped blind.

Third-Party Actions Every uses: some-org/action@v4 is a decision to execute code from a repo you don’t control, at a pointer that repo’s owner can move. Pin to a full commit SHA, not a tag — the tj-actions incident is precisely what an unpinned tag buys you. The cost is honest: SHA pinning trades silent compromise for silent staleness, so it needs Dependabot behind it to keep the pins current.

pull_request_target Trap pull_request_target runs with repository secrets and checks out the fork’s code. Combine those and an external pull request can execute attacker-controlled code with full access to your secrets. It’s one of the most common and most damaging mistakes in the whole ecosystem.

Secrets Stored the Old Way Long-lived AWS or GCP keys sitting in GitHub Secrets are a leak waiting for a log line. OIDC federation replaces them with short-lived tokens minted per run — but only if the cloud trust policy constrains the sub claim to specific branches or environments. An OIDC trust that omits that constraint authenticates any workflow in the repo and fails open, which is worse than the static key it replaced.

Self-Hosted Runner Risk A persistent self-hosted runner executing code from public-repo pull requests is a foothold on your network with a mutable filesystem the next job inherits. Use ephemeral, single-use runners, or keep self-hosted runners off public repositories entirely.

How We Review Your Pipeline

The review pairs automated checks with manual reading, because the dangerous findings — a privileged workflow that trusts a fork, a trust policy missing a sub constraint — are logic bugs no scanner flags:

1. Branch Protection & Access We verify main requires review before merge, and check for signed commits and linear history where the team’s model supports them. The point is that code can’t reach the deploy pipeline without a human in the loop.

2. Workflow Audit We read every .github/workflows/*.yml to map trigger conditions, what executes where, and which jobs land on GitHub-hosted versus self-hosted runners. The triggers are where the risk concentrates — pull_request_target, workflow_run and issue_comment deserve the most attention.

3. Secrets & Credentials We hunt hardcoded secrets, review environment protection rules, and plan the migration from static cloud keys to OIDC — including the sub-claim constraint that makes OIDC safe rather than merely modern.

4. Build Integrity & Dependencies We check that build outputs are handled without leaking secrets into logs, that cache poisoning is mitigated, and that Dependabot is watching for vulnerable packages — which is also what keeps SHA-pinned actions from silently rotting.

5. Code Security Scanning We confirm CodeQL, Checkov, Semgrep or equivalent are wired into the pipeline so vulnerable code is caught before merge, not after deploy. One caveat worth stating: GitHub’s secret-log masking is string replacement, defeated by any encoding, so it’s a backstop and never the control you rely on.

Tools We Use

GitHub’s own tooling plus targeted DevSecOps software, with the manual read carrying the findings automation can’t:

• GitHub Native — Advanced Security, CodeQL, Secret Scanning, Dependabot.
• Manual Review — Hand-audit of the YAML workflows and GitHub API settings, which is where the trigger-and-token logic flaws actually surface.
• Static Analysis — Semgrep, Checkov, and Open Policy Agent to enforce the rules as code once they’re agreed, so the standard survives the next new repo.

Common Problems & Solutions

Problem	Why It’s Bad	The Fix
Over-Privileged Tokens	GITHUB_TOKEN has read+write by default. Compromised workflow = malicious code pushed.	Set permissions: read-all globally. Grant write only to jobs that truly need it.
PR Code in Privileged Workflows	Running npm install from an untrusted PR in pull_request_target = attacker can execute code with full permissions.	Never run untrusted code in privileged context. Use pull_request (not pull_request_target) for external PRs.
Unpinned Action Versions	uses: actions/checkout@v3 — tag can be moved. Attacker can push malicious v3 tag.	Pin to commit SHA: uses: actions/checkout@a1b2c3d4... (immutable).
Static Cloud Credentials	AWS keys sitting in GitHub Secrets waiting to be leaked.	Use OIDC federation. GitHub Actions gets short-lived, temporary credentials instead.
Self-Hosted Runners on Public Repos	Persistent runner executing public PR code = total compromise + lateral movement.	Use ephemeral runners (single-use) or restrict self-hosted runners to private repos only.

What You Get

• Risk Report — Findings prioritised by what they actually enable, not by count, so the pipeline compromise ranks above the missing header.

• Fixed Workflow Examples — Real YAML showing the corrected pattern: scoped permissions, SHA-pinned actions, safe handling of fork pull requests.

• Secrets Migration Plan — The step-by-step move from static keys to OIDC, including the trust-policy sub constraint that’s the difference between secure and open.

• Branch Protection Checklist — The exact settings to lock down main, written to be applied, not just read.

• Developer Implementation Guide — Plain-language fixes staged so they harden the pipeline without breaking the deployments people depend on that afternoon.

30-Day Hardening Plan

Days 1–10: Baseline & Org-Level Controls Audit branch protection across the critical repos, set GITHUB_TOKEN to read-only at the organisation level, and turn on Dependabot and secret scanning. Expect the read-only default to surface a handful of workflows that quietly needed write — fixing those explicitly is the point, not a setback.

Days 11–20: Secrets & Dependencies Review every Environment and Secret, begin migrating cloud keys to OIDC (with the sub constraint from day one), and pin third-party actions to commit SHAs. Wire Dependabot to the pins so they don’t freeze vulnerabilities in place.

Days 21–30: Workflow Hardening Rewrite the workflows with job-scoped permissions, fix or remove anything abusing pull_request_target, and put manual approval gates in front of production deploys. The approval gate is the control that survives everything else being bypassed.

---

Hardening CI/CD is the shift from “trust by default” to “verify everything, pin everything, scope everything.” It costs some developer friction up front — pinning, approval gates, least-privilege tokens all add small frictions — and that friction is the price of a deployment path that’s as trustworthy as the code moving through it. The tj-actions victims paid the other price instead.