CI/CD Pipeline Security: Protecting Your Build and Deploy Process
Your CI/CD pipeline has access to your source code, your secrets and your production environment. That makes it one of the most valuable targets in your organisation. Compromise the pipeline, and an attacker can ship their code as yours.
How pipelines get attacked
Secrets exposure
- Secrets printed in build logs.
- Secrets available to pull requests from forks.
- Long-lived cloud keys stored as CI variables.
Poisoned pipeline execution
An attacker modifies pipeline configuration or build scripts in a pull request, and the CI system runs them with access to secrets. Workflows triggered on untrusted pull requests with elevated permissions are a common cause.
Compromised third-party actions and plugins
Pipelines often run third-party actions or plugins. If one is compromised, or referenced by a mutable tag that an attacker updates, malicious code runs in your build.
Dependency and artifact tampering
Malicious dependencies, or tampered build artifacts between build and deploy.
Self-hosted runners
Runners that persist between jobs, or that are shared across trust levels, let one job affect another, and can provide a foothold in your network.
Hardening your pipeline
- Use OIDC federation for cloud access instead of storing long-lived keys. Each job receives short-lived credentials scoped to its role.
- Restrict secrets to protected branches and environments. Pull requests from forks should never receive production secrets.
- Apply least privilege to pipeline tokens, setting default permissions to read-only and granting more per job.
- Pin third-party actions to commit SHAs, not tags, and review them before use.
- Require review for pipeline configuration changes, using code owners for CI files.
- Separate build and deploy, with deploys to production requiring approval or protected environments.
- Use ephemeral runners, fresh for each job, and avoid self-hosted runners for public repositories.
- Mask secrets in logs and avoid commands that echo environment variables.
- Sign and verify artifacts, and generate provenance, so you can prove what was built from what.
- Audit pipeline activity: who changed workflows, who approved deploys, and which secrets were accessed.
A risky pattern to look for
Workflows that run on events from untrusted pull requests with write permissions or secrets, and then check out and execute the pull request's code, effectively let anyone run code with your privileges. Review every workflow triggered by external contributions.
CI/CD security checklist
| Control | Done? |
|---|---|
| OIDC instead of static cloud keys | |
| Secrets limited to protected environments | |
| Read-only default token permissions | |
| Actions pinned to SHAs | |
| Code owners on CI configuration | |
| Production deploy approval | |
| Ephemeral runners | |
| Artifact signing |
Finding exposed pipeline secrets
Secrets from CI often leak into logs, artifacts and public repositories. SecurityInfinity's secrets agent scans public code and exposed files for leaked credentials, and its attack surface agents find exposed CI servers and dashboards. Start free.
Frequently asked questions
Why pin actions to a commit SHA?
Tags can be moved to point at different code. A commit SHA is immutable, so the code you reviewed is the code that runs.
Are self-hosted CI servers riskier than hosted CI?
They can be, if exposed to the internet, unpatched or shared across trust levels. Hosted CI shifts some responsibility to the provider.
What is SLSA?
Supply-chain Levels for Software Artifacts, a framework for improving build integrity through provenance and hardened build processes.