Securing CI/CD Pipelines

A CI/CD pipeline has privileged access to source code, secrets, and production. Compromising it lets an attacker inject backdoors into every future build while bypassing code review. It is one of the highest-value targets in modern engineering.

Treat the pipeline as production infrastructure: it deserves the same hardening, monitoring, and least-privilege discipline as your live systems.

Pipelines run automatically on events you do not fully control: pull requests, tags, external contributions. A malicious PR can try to alter the build itself.

• A poisoned pipeline definition in a fork can attempt to exfiltrate secrets
• Untrusted code may run with the same permissions as trusted builds

Separate trusted and untrusted workflows: do not expose secrets to jobs triggered by external pull requests.

Pipeline steps often pull third-party actions or container images by mutable tag. If that tag is re-pointed to malicious content, your build is compromised. Pin to immutable digests.

Default pipeline tokens are often over-permissioned, granting write access to the whole repository or registry. Scope them down to exactly what each job needs.

Hardcoded or broadly shared secrets are a primary leak path. Apply strict handling:

• Store secrets in a secrets manager or the CI secret store, never in code
• Prefer short-lived OIDC federation over static cloud keys
• Mask secrets in logs and block their echo
• Scope each secret to the minimum jobs and environments

OIDC federation lets the pipeline exchange a build-time identity for short-lived cloud credentials, removing long-lived keys entirely.

A reused build runner can carry malware or leaked secrets from one job to the next. Ephemeral runners are created fresh per job and destroyed afterward, so nothing persists.

• One clean environment per build, then discarded
• No shared state between trusted and untrusted jobs
• Network egress restricted to required endpoints

This directly supports SLSA L3 isolation goals.

The pipeline's trust starts at source control. If anyone can push to the release branch, signing and scanning downstream are moot.

• Require pull request review before merge
• Enforce signed commits on protected branches
• Require status checks (tests, scans) to pass
• Disallow force-push and direct push to main

Bake security gates directly into CI so issues fail the build rather than reaching production.

High-impact actions deserve a human gate. Production deploys and credential changes should require approval from someone other than the author.

• Environment protection rules require a reviewer before deploy
• Separate the build identity from the deploy identity
• No single actor can both author code and push it to production unreviewed

This limits both insider risk and the blast radius of one compromised account.

You must be able to reconstruct what the pipeline did. Centralize and protect its logs.

• Ship CI logs to an append-only, access-controlled store
• Record who changed pipeline definitions and when
• Emit signed provenance so artifacts trace back to a specific build
• Alert on anomalies: new self-hosted runner, unexpected secret access, config change outside review

A defensible pipeline combines source, build, and release controls:

• Branch protection, reviewed and signed commits
• Pinned actions and images by digest
• Least-privilege, short-lived OIDC tokens
• Ephemeral isolated runners
• In-pipeline secret, dependency, and config scanning
• Two-person release approval
• Signed artifacts, SBOM, and provenance with audit logging

Decide the right control for a privileged build token.

You learned to harden the entire build and release path.

• Treat the pipeline as production; it can backdoor every future build
• Isolate untrusted PR builds from secrets
• Pin actions and images by digest; use least-privilege, short-lived OIDC tokens
• Use ephemeral isolated runners and protect the source branch
• Scan in-pipeline, require two-person release approval, and keep tamper-evident audit logs

Course complete: you can now secure the software supply chain end to end.