How to Secure a CI/CD Pipeline Step-by-Step

A CI/CD Pipeline Is a Privileged System, Not Just Automation

Build systems hold source code, signing paths, deployment authority, and secrets. That makes them one of the highest-value targets in the organization.

SolarWinds, Codecov, and other pipeline-related incidents taught the same lesson from different angles: if an attacker compromises the build path, they do not need to compromise every downstream environment one by one.

Here is the practical way to secure a pipeline.

Step 1. Decide What Code Is Trusted to Run

Before anything else, separate trusted and untrusted code paths.

Questions to answer:

• Do external pull requests run automatically?
• Which workflows can access secrets?
• Which branches can produce deployable artifacts?
• Which events can request cloud credentials?

If the system cannot answer those questions clearly, the pipeline is already riskier than it should be.

Step 2. Remove Long-Lived Secrets From the Pipeline

Prefer workload identity and OIDC over stored cloud keys.

Use cases:

• GitHub Actions to AWS IAM role via OIDC
• GitLab CI to cloud roles without static secrets
• short-lived tokens for deployment rather than reusable shared keys

This single change removes one of the most common paths to credential theft.

Step 3. Pin and Verify Dependencies Used by the Pipeline

Pipelines consume more than application dependencies. They also consume actions, plugins, containers, and packages.

Checklist:

• Pin third-party actions by commit SHA
• Use lockfiles for application dependencies
• Prefer official or reviewed actions and runners
• Review reusable workflow imports and templates

The 2025 tj-actions/changed-files compromise is a good reminder that even popular CI dependencies can become attack paths.

Step 4. Harden the Build Environment

Use ephemeral runners when possible.

Why:

• less cross-job residue
• easier cleanup after suspicious runs
• lower chance of persistence surviving between builds

If you must use self-hosted runners, isolate them by repository sensitivity and keep them short-lived where practical.

Step 5. Sign What You Produce

Unsigned artifacts force everyone downstream to trust the build system blindly.

A stronger flow looks like this:

1. Build artifact
2. Generate provenance
3. Sign image or binary
4. Verify signature before deployment

That is where SLSA and Sigstore become useful, not just fashionable.

Step 6. Split Testing and Deployment Privileges

Your test job and your production deploy job do not need the same power.

Good pattern:

• test jobs get read-only repository access and no production secrets
• deploy jobs run only after review gates and branch checks
• production environment approvals exist for sensitive releases

Step 7. Log the Right Pipeline Events

You should know when:

• a workflow file changes
• a new reusable workflow or third-party action appears
• permissions are elevated
• a runner image changes
• signing or deployment steps fail verification

If those changes happen silently, you are relying too much on hope.

Step 8. Rehearse Incident Response for the Pipeline Itself

Pipeline compromise response should be documented before you need it.

Include:

• disabling risky workflows quickly
• rotating secrets and tokens
• invalidating artifacts built during the suspect window
• verifying whether releases need revocation or redeployment

Step-by-Step CI/CD Security Checklist

• Untrusted code paths identified
• OIDC or short-lived credentials in place
• Third-party actions pinned and reviewed
• Runners isolated or ephemeral
• Artifact signing enabled
• Deployment authority separated from test authority
• Workflow changes monitored
• Response plan documented and exercised

Further Reading

• CISA Defending Continuous Integration/Continuous Delivery Environments
• SLSA Framework
• NIST Secure Software Development Framework
• GitHub Hardening for GitHub Actions

Related SecureCodeReviews guides:

• CI/CD Pipeline Security: 8 Attacks We See in Every Audit
• GitHub Actions Security Hardening
• How to Prevent Supply Chain Attacks in CI/CD

The strongest pipeline control is not a single scanner. It is a build system that trusts less code, exposes fewer secrets, and produces artifacts that can be verified later.