How to Harden a CI/CD Pipeline: A Practical Checklist

To harden a CI/CD pipeline, give every job the least privilege it needs, pin everything it pulls in, replace stored credentials with short-lived ones, run jobs on clean isolated runners, require review on pipeline configuration, and sign what the pipeline produces so deploys can verify it.

Key takeaways

• The pipeline holds your deploy keys. Treat it as production.
• Least privilege, applied per job, limits what one bad step can do.
• Short-lived credentials beat stored ones.
• Ephemeral runners stop one build from poisoning the next.
• Verify at deploy: signatures, scans and approvals.

Why is the pipeline an attack target?

It can read source, hold secrets and push to production. An attacker who controls one step often gets all three. Hardening reduces what a single compromised step, action or dependency can reach.

How do I apply least privilege to jobs?

Set tokens to read-only by default and widen per job. GitHub's hardening guide recommends read access only for repository contents as the default GITHUB_TOKEN permission. Other platforms have equivalents: scope service accounts and deploy keys to one repository and one environment.

How do I handle credentials?

Prefer short-lived credentials from OpenID Connect over stored keys. Each job requests a token valid for a single job, and the cloud role can restrict access by repository, ref and environment. Where you must store secrets, keep one value per secret, gate production secrets behind required reviewers, and rotate on a schedule. See how to rotate secrets safely.

How do I control what the pipeline pulls in?

Pin third-party actions and plugins to full-length commit SHAs, install from lockfiles with commands that fail on drift, and audit the source of any action before adopting it. Dependabot version updates keep pins current, though its alerts do not cover SHA-pinned actions. Details in how to pin dependencies.

How do I harden runners?

Use ephemeral or just-in-time runners that start from a clean environment. GitHub advises against self-hosted runners for public repositories, since any pull request author could try to compromise them. Minimize sensitive data and network access on runners, and use runner groups to limit blast radius.

How do I protect the pipeline configuration?

Treat workflow files as code. Use CODEOWNERS, require approving reviews and status checks through branch protection, avoid pull_request_target with untrusted checkouts, and never interpolate untrusted input such as pull request titles into shell lines. Walkthrough: how to secure GitHub Actions.

How do I make build outputs trustworthy?

Sign them and verify at deploy. Cosign keyless signing records each event in a transparency log, and consumers verify identity and issuer. See how to sign container images and releases. Add a dependency scan on every build: the free Safeguard scan runs in the browser with no login for up to 100 dependencies.

CI/CD hardening checklist

• Default token read-only; wider per job.
• Cloud access via OIDC, not stored keys.
• Actions and plugins pinned by SHA.
• Installs from lockfiles that fail on drift.
• Ephemeral runners, no self-hosted on public repos.
• CODEOWNERS and branch protection on pipeline files.
• No untrusted input in shell lines.
• Artifacts signed and verified at deploy.

Frequently asked questions

Sources

• Security hardening for GitHub Actions
• About security hardening with OpenID Connect
• Sigstore cosign signing overview
• About protected branches

Last reviewed: 19 October 2026.