Continuous Integration / Continuous Delivery (CI/CD)

What CI/CD means in security practice

CI/CD is more than a developer workflow, it is an automated delivery path that moves code from commit to build, test, and release. That makes it a control plane for software change: if the pipeline is trusted, fast, and repeatable, teams can ship safely; if it is weakly governed, the pipeline itself becomes a high-value target.

The security significance of CI/CD comes from its reach. A pipeline can read source code, fetch dependencies, sign or package artifacts, deploy to environments, and handle credentials that connect tools, registries, cloud services, and deployment targets.

Why CI/CD changes the attack surface

CI/CD expands the attack surface because compromise at one point in the workflow can influence many downstream systems. Build steps, runner hosts, secrets stores, action or plugin ecosystems, artifact repositories, and deployment permissions all become part of the trust boundary.

That is why pipeline security is not only about code quality checks. It also depends on tight control of third-party integrations, token scope, artifact integrity, and the isolation of build and release environments.

Pipeline compromise is especially dangerous because attackers often want the same thing defenders want from CI/CD, trusted automation. If an adversary can alter build logic, poison dependencies, or abuse a trusted integration, they can turn ordinary delivery activity into a distribution channel for malicious code or secret theft. See the Shai Hulud npm malware campaign for a concrete example of how CI/CD-adjacent supply chain abuse can expose secrets.

Core controls for trustworthy pipelines

A secure CI/CD design makes the pipeline observable, constrained, and reproducible. The important questions are whether the workflow is pinned to known inputs, whether credentials are short-lived and narrowly scoped, whether privileged deployment steps are separated from routine test activity, and whether changes to pipeline definitions are reviewed as carefully as application code.

Build provenance matters because release systems are often asked to prove where an artifact came from and what produced it. Integrity checks on source, dependency, build output, and signing material reduce the chance that an altered dependency or tampered build step can silently enter production. SLSA is useful here because it formalises provenance and integrity expectations for software artifacts.

Operationally, the most effective controls often focus on reducing standing trust inside the pipeline. That includes limiting reusable tokens, isolating runners, controlling who can change workflow files, and using approvals or environment gates for production release actions. The OWASP CI/CD Top 10 CICD-SEC-8 Ungoverned Usage of Third-Party Services Guide is a practical reference for governing external services that plug into delivery pipelines.

Monitoring, auditability, and release confidence

CI/CD also changes how defenders detect problems. Security teams need enough logging to reconstruct who changed the pipeline, what ran, what secrets were used, which environments were touched, and whether a release followed the expected path. Without that visibility, a compromised pipeline can look like normal automation.

Good logging supports both detection and recovery. It helps teams spot suspicious workflow edits, unusual build triggers, unexpected artifact changes, and abnormal deployment activity, then trace the blast radius if a pipeline or build credential has been abused. The OWASP CI/CD Top 10 CICD-SEC-10 Insufficient Logging and Visibility Guide maps that visibility problem directly to pipeline operations.

Post-release assurance matters too. When a pipeline has been tampered with, teams should review not only the deployed artifact but also the workflow history, runner activity, integration tokens, and any credentials that may have been exposed during the compromise window.

Practitioner Guidance

Governance implication: Treat CI/CD as a production control surface, not just a developer convenience layer. Ownership should cover pipeline definitions, build identities, release permissions, artifact integrity, and third-party integrations, because failures in any of those areas can affect the trustworthiness of every release.

What to watch for: Reused long-lived tokens, overbroad plugin or app access, unsigned or unpinned dependencies, and weak audit trails are all signs that the delivery system is accumulating avoidable risk. If those conditions exist, the pipeline may be fast but not trustworthy.

Practitioner takeaway: A mature CI/CD program balances speed with verifiable control, so teams can release quickly without making the release path itself an easy compromise point.

Related resources from NHI Mgmt Group

• Continuous Delivery (CD)
• Continuous Integration (CI)
• Continuous Integration And Continuous Deployment (CI/CD)
• What do teams get wrong about securing CI/CD integration?