CI/CD pipelines explained: how they speed up releases, and how to keep them secure
A CI/CD pipeline turns every code change into a tested, deployable release. It also holds the keys to production, which makes it a target.
Continuous integration and continuous delivery, usually shortened to CI/CD, is the automated path code takes from a developer's commit to production. For IT leaders, it matters for two reasons: it decides how fast your teams can ship fixes and features, and it is one of the most privileged systems you run.
What each half does
Continuous integration means every change a developer commits is automatically built and tested, many times a day. Problems show up within minutes, while the change is still small and fresh in the developer's mind.
Continuous delivery takes the next step. Every change that passes its tests is packaged and ready to release, so deploying becomes a routine button press rather than a weekend project. Continuous deployment goes further still and releases every passing change automatically.
A typical pipeline runs the same stages each time: build the code, run unit and integration tests, scan for security issues and vulnerable dependencies, package the result, deploy to a test environment, and then promote to production.
How to tell if it's working
The DORA research program, now run by Google, tracks software delivery with five metrics. Three measure speed and two measure stability.
| Metric | What it measures | Type |
|---|---|---|
| Change lead time | How long a change takes to go from commit to running in production | Speed |
| Deployment frequency | How often you deploy | Speed |
| Failed deployment recovery time | How long it takes to recover when a deployment breaks something | Speed |
| Change fail rate | The share of deployments that need a rollback or hotfix | Stability |
| Deployment rework rate | The share of deployments that are unplanned and caused by a production incident | Stability |
Ask your engineering leads for these numbers. They are a better guide to delivery health than headcount or tool spend, and the trend matters more than any single reading.
Why attackers want your pipeline
A pipeline can read source code, hold cloud credentials and push code to production. Compromise it, and an attacker can ship malicious code that looks like a normal release.
In June 2023, the NSA and CISA published joint guidance on defending CI/CD environments. Their recommendations, as summarized by Infosecurity Magazine:
- Minimize long-term credentials, and use short-lived tokens instead.
- Require two-person review for code changes.
- Secure the user accounts that can access the pipeline.
- Give each person and service the least access it needs.
- Sign code and build artifacts so you can verify what you deploy.
- Segment the network around build systems.
- Scan regularly for vulnerabilities.
- Build security checks into the pipeline itself.
None of these needs a new product. Most are settings in the CI/CD tools you already use, such as GitHub Actions, GitLab or Azure DevOps.
What IT teams should do
- Ask engineering for your current change lead time and change fail rate.
- Find every long-lived secret stored in your pipelines and plan to replace it with short-lived credentials.
- Require a second reviewer before changes merge to the main branch.
- Check who has admin rights on your CI/CD platform, and cut the list.