Continuous Delivery (CD) is a software delivery practice where changes are automatically built, tested, and prepared for release, with deployment to production controlled by a final approval or trigger. Security teams should secure the pipeline, protect signing secrets and service connections, and enforce review and release controls, because compromised CD can publish malicious code or configuration.
How Continuous Delivery Works
Continuous Delivery is built around a repeatable pipeline that compiles code, runs automated checks, and packages release candidates so they are always in a releasable state. The defining feature is not automatic production deployment, but the discipline of keeping delivery ready and controlled.
This model changes software delivery from occasional release events into an ongoing operational process. That means teams must treat build integrity, test coverage, approval logic, and release automation as first-class parts of the system rather than as after-the-fact coordination work.
Why CD Becomes a Security Boundary
CD pipelines often have broad access to source code, build systems, artifacts, signing material, and deployment permissions. If an attacker can alter the pipeline, they can turn trusted automation into a distribution channel for malicious code or unsafe configuration.
The security concern is not just whether the application is secure, but whether the release mechanism can be trusted. A compromised delivery path can affect every downstream environment that relies on the pipeline’s output, including production, staging, and any automated rollback or promotion flow.
Core Controls for Safe Continuous Delivery
Secure CD depends on protecting the highest-value pipeline assets: signing keys, service connections, build runners, and release approvals. Those controls matter because delivery trust is only as strong as the weakest privileged integration in the chain.
Strong practice usually includes isolated build execution, strict branch and pull request review rules, immutable or provenance-checked artifacts, and tightly governed secrets handling. Release control should be explicit, so that a successful build does not automatically become a production change without the intended approval path.
It also helps to separate build-time trust from deploy-time trust. A pipeline that can compile and test code should not automatically inherit unrestricted production authority unless that authority is clearly required and continuously justified.
Continuous Delivery in the Broader Software Lifecycle
CD sits between continuous integration and production release management, so it is one of the main places where engineering speed and operational control meet. When it is implemented well, teams can release faster without turning every deployment into a manual event.
That benefit comes from standardisation. Reproducible builds, consistent test gates, and predictable promotion rules reduce release friction while also making failures easier to understand and contain. In mature environments, CD is as much about reliability and governance as it is about speed.
For teams mapping delivery maturity, OWASP SAMM is useful because it frames secure delivery as a development practice that can be assessed and improved over time.
Risk and Threat Considerations
CD is attractive to attackers because it concentrates trust, automation, and privileged access in one place. If a delivery pipeline is poisoned, the result can be rapid propagation of malicious code, hidden backdoors, or altered configuration across many systems before the issue is noticed.
Failure mechanism: An attacker compromises source control, a build runner, a service connection, or signing material, then uses the trusted pipeline to publish artefacts that appear legitimate to downstream systems and reviewers.
Impact: The organisation may distribute malicious or tampered software at scale, lose confidence in release integrity, and have to rebuild trust in artifacts, credentials, and deployment history after the compromise is contained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | SDP — Deployment | CD is a software delivery practice that SAMM helps mature with secure release processes. |
| Recommendation — Assess and harden release practices so deployment steps preserve integrity and review. | ||
| SLSA | Supply-chain integrity | CD depends on artifact provenance and build integrity, which SLSA directly addresses. |
| Recommendation — Adopt stronger provenance and integrity checks for build outputs before promotion. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | CD release control hinges on governed changes to pipeline and production configurations. |
| IA-5 — Authenticator Management | CD pipelines rely on secrets and credentials that must be protected and rotated. | |
| AU-2 — Audit Events | CD needs traceable build and release activity to support integrity review after changes. | |
| Recommendation — Enforce approval and traceability for pipeline and release configuration changes. Manage pipeline credentials with rotation, protection, and lifecycle controls. Log pipeline actions and release events so changes can be investigated quickly. | ||
Practitioner Guidance
Governance implication: Treat CD as a high-trust production system, not just a developer convenience. Ownership should span engineering, security, and operations, because the same pipeline can affect code integrity, access control, and release authority.
What to watch for: Review bypasses, unexpected changes to pipeline definitions, excessive permissions on service connections, and long-lived signing or deployment secrets are all signs that delivery trust is weakening. A secure pipeline is one that can be inspected, constrained, and rotated without relying on informal tribal knowledge.
Practitioner takeaway: The safest CD design assumes the pipeline itself is a target, so release speed should never come at the cost of provenance, review, or controlled promotion.
Related resources from NHI Mgmt Group
- Guide: CI/CD Security Guide
- What changes when identity platforms move to continuous delivery?
- Why do DAST findings become less reliable in continuous delivery environments?
- Why do continuous delivery environments increase validation risk?
- How should teams align security testing with continuous delivery?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org