Cybersecurity glossary
What is a CI/CD Pipeline?
Learn what a CI/CD pipeline is, how continuous integration and delivery automate software releases, and which security controls protect pipelines from abuse.
Definition
A CI/CD pipeline is an automated workflow that continuously integrates code changes, verifies them with tests and checks, and delivers or deploys approved artifacts to target environments with minimal manual release friction.
Why CI/CD pipelines matter
Modern software changes too often for weekly hand releases. A CI/CD pipeline turns every meaningful change into a verified candidate: integrate early, test automatically, and promote with policy instead of tribal knowledge.
When security is bolted on after packaging, pipelines become a race to production. When security is encoded as gates, speed and assurance reinforce each other.
CI vs CD responsibilities
Continuous Integration
Merge frequently, build on every change, and catch breakages with automated tests and scans.
Continuous Delivery
Keep mainline releasable and automate packaging up to a controlled promotion decision.
Continuous Deployment
Push every passing change to production automatically under strict policy.
Feedback loops
Telemetry, incidents, and failing gates flow back into developer workflows quickly.
End-to-end CI/CD flow
Change submitted
A pull request or commit triggers pipeline execution against the proposed revision.
Integrate and verify
Build, unit/integration tests, lint, and early security scans run in isolation.
Produce artifacts
Versioned packages, images, SBOMs, and signatures are created from pinned inputs.
Promote through environments
Staging validation, approvals, and policy checks precede production access.
Deploy and observe
Rollouts use progressive delivery; metrics and security signals watch for regressions.
Pipeline stages and security focus
| Stage | Primary goal | Security focus |
|---|---|---|
| Source control | Collaborate on trusted history | Branch protection, signed commits, CODEOWNERS |
| CI build/test | Prove the change works | SAST, SCA, secrets, untrusted PR isolation |
| Artifact publish | Store releasable outputs | Signing, provenance, immutable registries |
| CD deploy | Ship to environments | Least privilege, approvals, runtime policy |
CI/CD hardening checklist
- Protect default branches and require reviews for pipeline and IaC changes.
- Use short-lived workload identities instead of long-lived cloud keys when possible.
- Pin third-party CI actions and build images by digest.
- Separate PR workflows from privileged release workflows.
- Scan for secrets in code, configs, and pipeline logs.
- Enforce environment protections and manual approvals for production.
- Record who deployed what artifact digest to which environment.
- Treat self-hosted runners as high-value hosts with strong isolation.
The practical takeaway
A CI/CD pipeline automates integration, verification, and delivery so teams can ship frequently with confidence. It is also privileged infrastructure that can mint and deploy trusted software.
Encode quality and security as pipeline policy, minimize standing privileges, and prove artifact integrity end to end. Fast delivery is only an advantage when the path itself is trustworthy.
Related security terms
Build Pipeline
The CI portion that turns source into verified artifacts.
Shift Left Security
Embedding security checks early in the CI/CD flow.
Pipeline Poisoning
Attacks that compromise pipeline steps to ship malicious software.
Secret Scanning
Detecting credentials that should never enter repositories or logs.
Supply-chain Levels for Software Artifacts (SLSA)
A framework for hardening and attesting build integrity.
Frequently asked questions
What does CI/CD stand for?
Continuous Integration and Continuous Delivery (or Continuous Deployment). CI merges and verifies changes often; CD automates release readiness or production rollout.
What is the difference between continuous delivery and continuous deployment?
Delivery keeps every good build releasable, often with a manual approve step. Deployment automatically pushes approved builds to production.
Why is CI/CD a security concern?
Pipelines hold credentials, can modify production, and define what code is trusted. Attackers who alter pipeline config can bypass many app-layer defenses.
Where should security tests run in CI/CD?
As early as practical on pull requests for fast feedback, plus deeper scans and signed attestations on release candidates before production.
Do all teams need full continuous deployment?
No. Many regulated teams stop at continuous delivery with controlled promotion. The value is repeatable automation and clear gates, not mandatory auto-prod.
What breaks CI/CD security most often?
Over-privileged tokens, mutable third-party actions, unprotected branches, secrets in logs, and self-hosted runners shared across untrusted projects.
How do feature flags relate to CI/CD?
Flags separate deploy from release so code can ship dark and be enabled safely, reducing emergency hotfixes that skip pipeline controls.
References
Explore authoritative guidance and frameworks related to ci/cd pipeline.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.