Continuous integration and continuous delivery, or CI/CD, are automated software release practices that merge, test, and deploy changes frequently. They create speed and consistency, but also concentrate risk because the same pipelines often handle code, secrets, certificates, and production permissions.
Expanded Definition
Continuous integration and continuous delivery, commonly called CI/CD, is the automated pipeline model that takes code from commit through build, test, packaging, and release with minimal manual intervention. In security terms, the key issue is not just speed, but the concentration of trust in the pipeline itself: source repositories, build runners, artifact stores, deployment permissions, NIST Cybersecurity Framework 2.0 controls, and the secrets used to move software across environments.
Definitions vary across vendors on where CI ends and CD begins, but the practical distinction is useful. CI focuses on integrating changes early and validating them automatically. CD extends that discipline into controlled release, often with policy gates, approvals, and rollback logic. In mature environments, CI/CD also includes infrastructure-as-code checks, dependency scanning, signed artifacts, and environment promotion rules. The term is sometimes used loosely to describe any automated release workflow, but that overstates maturity when manual handoffs still determine production readiness. The most common misapplication is treating a partially automated build-and-deploy script as CI/CD, which occurs when testing, approval, and release governance are not integrated into the same pipeline.
Examples and Use Cases
Implementing CI/CD rigorously often introduces more pipeline governance and secret-handling overhead, requiring organisations to weigh release velocity against tighter controls on who can change, sign, and deploy software.
- A development team runs automated unit, integration, and dependency checks on every pull request, then blocks merges until failures are resolved.
- A platform team uses signed build artifacts and an approval gate before production release, reducing the risk of tampered binaries reaching users.
- A security team adds secret scanning and OWASP guidance-style pre-deployment checks to prevent API keys and tokens from being committed into pipeline variables or configuration files.
- An operations team promotes the same immutable artifact from staging to production, rather than rebuilding separately for each environment, to preserve release integrity.
- A regulated organisation ties deployment to change tickets, segregation of duties, and rollback validation so that release automation still satisfies audit expectations.
These use cases show that CI/CD is not just a developer convenience. It is a security boundary that can either compress risk into a well-governed workflow or spread it across ad hoc scripts and manual exceptions. For identity-sensitive environments, the pipeline often becomes a privileged path because it can mint credentials, deploy agents, or update services that hold access tokens. That is why secure pipeline design increasingly overlaps with supply chain assurance, identity governance, and CISA supply chain risk management practices.
Why It Matters for Security Teams
Security teams care about CI/CD because it is one of the fastest ways attackers can turn a single code change into widespread compromise. If build systems are not protected, an adversary may insert malicious code, steal secrets from pipeline logs, abuse over-privileged service accounts, or poison artifacts before they reach production. That makes CI/CD a governance problem as much as an engineering one. Controls around least privilege, code signing, branch protection, test integrity, and environment separation map naturally to the broader NIST Cybersecurity Framework 2.0 approach to protecting assets and maintaining operational resilience.
For identity and access practitioners, CI/CD is especially important because pipelines commonly rely on non-human identities, short-lived tokens, certificates, and delegated permissions to function. If those identities are not governed like production credentials, the pipeline becomes a standing privilege corridor into critical systems. Mature teams treat pipeline identity, secret rotation, artifact provenance, and approval logic as first-class security controls, not developer conveniences. Organisations typically encounter the consequences only after a compromised repository, leaked token, or unauthorized deployment forces a production rollback, at which point CI/CD becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | CI/CD depends on controlled access, least privilege, and governed pipeline permissions. |
| OWASP Non-Human Identity Top 10 | CI/CD often creates and uses non-human identities, tokens, and certificates that need governance. | |
| NIST SP 800-53 Rev 5 | SA-10 | Secure development and testing controls align with pipeline integrity and change assurance. |
| NIST SP 800-63 | AAL2 | Strong authentication is relevant where engineers approve releases or access privileged pipeline functions. |
| NIST Zero Trust (SP 800-207) | Zero Trust principles fit CI/CD by verifying every actor and workload before release actions. |
Restrict pipeline credentials and deployment rights to the minimum required for each release stage.
