The Continuous Integration/Continuous Delivery or Deployment (CI/CD) pipeline integrates and tests code changes, often multiple times per day. And it automatically prepares code for release, sometimes automatically pushing code changes all the way to production without manual intervention.
Practicing CI/CD today means faster delivery, more updates, and happier customers, all with fewer errors.
But it also means a new attack surface and the spectre of supply chain poisoning, insufficient artifact provenance, blind spots, secrets sprawl, and over-automation without controls. We’ve explored the increasing positioning of security within the DevOps pipeline as DevSecOps, but it’s worth going deeper into the pipeline itself. Are existing controls enough? And if not, what do teams need to do to ensure they can continue delivering and automating at scale without compromising control or visibility?
What is the CI/CD Pipeline?
The CI/CD pipeline is an automated series of steps that takes code from development to production. Continuous Integration means automatically testing and incorporating code changes as they are committed. Continuous Delivery means automatically delivering those changes to staging environments. One step further, continuous deployment removes human oversight from the loop, letting code go straight to production automatically.
The CI/CD pipeline typically includes:
- Code commit, where developers push code to a shared repository
- Build, where the pipeline compiles the code, installs dependencies, and builds artifacts or containers
- Automated Tests, where unit tests, integration tests, and security scans check code for quality
- Artifact storage, where the built application is stored in a repository
- Approval gates, in which many pipelines include analysts to review and approve or block the release
- Deploy to environment, where the application is deployed to dev, staging, or production, often automatically in mature pipelines
The CI/CD pipeline isn’t ubiquitous.
According to surveys, 53% of enterprise teams use continuous integration, while just 38% utilize continuous delivery and just 29% embrace continuous deployment.
Which controls to use to secure the pipeline also differ between organizations. Some enterprise CI/CD controls include code signing, secrets management, role-based access control (RBAC), and policy enforcement at every stage of the pipeline. By integrating solutions such as static analysis tools, vulnerability scanners, and policy-as-code monitoring tools, enterprise teams can ensure that security is built into the development lifecycle.
Ultimately, approaching development as a pipeline with continual checks pre-production is part of adopting a shift-left security approach and minimizing complicated re-architecting and interruptions to service that could emerge when issues are only found post-deployment.
What is CI/CD Pipeline Security?
CI/CD pipeline security is about the practices, tools, and policies that protect the automated systems that build, test, and deploy software. Whether the organization is just starting to automate deployments or running a mature DevOps model, securing the pipeline is foundational, as a compromise here can mean compromise everywhere.
Here’s how to think about CI/CD pipeline security at different stages of automation maturity:
Partial Automation with Manual Deployments
Risks at this stage include hardcoded secrets, inconsistent environments between staging and production, human error in manual deployments, and a lack of audit trails.
At this stage, security should focus on source code scanning and secret detection, using role-based access for repositories and build servers, and enforcing manual approvals before production.
CI in Place, with CD Emerging
Risks at this stage move to unverified or unsigned build artifacts, over-permissioned pipeline accounts, misconfigured runners or environments, and incomplete visibility into what gets deployed.
Focus on adding artifact signing, using environment isolation for build and deploy stages, rotating and scoping deployment credentials, and scanning containers and IaC before deployment.
Fully Automated CI/CD Across Environments
At this stage, the CI/CD system becomes a privileged attack path. Threat actors can target automation logic, with poisoned plugins or malicious PRs. Drift between IaC and deployed reality becomes a risk, as does insider misuse of credential capabilities.
The security focus for mature pipelines includes threat modeling the pipeline as infrastructure, integrating with Cloud-Native Application Protection Platforms (CNAPPs) or other runtime security platforms, using zero-trust access and audit logs for all automation actors, and continuously validating deployment integrity and provenance.
CI/CD-Aware Runtime Security with Upwind
Upwind connects runtime container monitoring with CI/CD activity, giving you real-time threat detection, contextualized analysis, and root cause visibility tied back to the build, artifact, and identity that introduced the risk. That means faster remediation for workloads, but also the pipeline behavior behind them.
Mapping the CI/CD Attack Surface: Beyond Pipeline Basics
As organizations move from partial to fully automated CI/CD pipelines, the attack surface expands from source control to build infrastructure and finally, to runtime deployments. Mature CI/CD environments are no longer code-moving assembly lines. They have become production control planes with privileged access across cloud accounts, secrets vaults, and workload clusters.
Each component introduces its own trust boundary and failure mode.
| Component | Weakness | Risk | Focus Area |
| Source repository | Weak branch protection, PR review gaps | Code injection, token theft | Enforce signed commits, PR reviews |
| Build systems | Shared runners, vulnerable plugins | Artifact tampering, lateral movement | Isolate runners, verify provenance |
| Third-party tools | Unvetted packages, plugin sprawl | Supply chain malware, data exfiltration | Use SBOMs, restrict integrations |
| Secrets management | Hardcoded or leaked credentials | Unauthorized access, privilege escalation | Centralize, rotate, scan for secrets |
| Artifact storage | Unsigned or unverified images | Malicious deploys, runtime compromise | Sign artifacts, validate digests |
| Iac deployments | Over-permissive roles, configuration drift | Pre-runtime exposure, exploit paths | Scan IaC, enforce parity, policy gates |
| Runtime deploys | Untracked changes, GitOps bypasses | Silent drift, unauthorized deploys | Link runtime to deploy identity/events |
While it’s important to shore up each stage, it’s also true that true security is about how the stages connect and trust deeply, often without enforcing identity, integrity, or visibility across transitions.
Pipelines Move Faster than Governance
That means that pipelines often outpace governance. They include provisioning, secrets injection, and configuration changes. But teams still try to enforce controls at discrete points, like with static analysis during commit or runtime detection after deploy.
What if threats enter during the pipeline orchestration itself? A rogue plugin or poisoned runner may not modify source or runtime behavior directly, but instead rewrite how trusted steps can execute. These meta-attacks are invisible to traditional controls since they don’t target the code itself.
Identity is Fractured
It also means that identity is fractured, and often even missing. Each stage of the pipeline can operate under a different identity. And these identities aren’t linked end to end. Many aren’t even human, so multi-factor authentication or approval policies are off the table. Some are shared, static, or tied to long-lived tokens. Identity traceability is key.
Security Controls are Linear, while Pipelines Aren’t
Security tools can be structured around code, build, scan, deploy, and monitor cycles. Yet real pipelines can use parallel branches, skip steps, and rely on environment-specific conditions. That means there are controls that can also be skipped.
Secrets, Dependencies, and Runtime Risk are Interdependent
Steps can look secure in isolation but together, they enable low-noise privilege escalation. Breach paths often involve the chained exploitation of all three, but ownership might be assigned by domain, so no one maps the compound path.
Artifact Integrity is the Root Enabler
Verify that what is running in production matches what was reviewed in the source. Besides scanning code and containers, sign artifacts, enforce hash validation at deploy, and track which build produced which binary. Pipelines are vulnerable to post-commit, pre-deploy tampering, like that which caused the SolarWinds breach. Without provenance, teams are vulnerable.
Drift and Shadow Automation are the Norm
And as pipelines grow, fragmentation does, too. Which pipelines are active? Which are secure? Ad hoc scripts emerge to push hotfixes. Legacy Jenkins jobs run parallel to GitHub actions. IaC is forked, not templated, and slowly diverges. It’s all likely, but creates shadow automation, as jobs are no longer tracked, reviewed, or secured.
Nuanced Risk Lives in the Gaps
Mapping components and their weaknesses and risks, like we did earlier in this section, is valid. Those risks are clear and valid. They’re even adequate. But they don’t always hold up when systems scale or get messy.
The table is a starting map. But the real terrain isn’t so simple. Real risk lives in the gaps, and moving between components requires layered security that understands the entirety of the pipeline, not just components in isolation.
Tensions and Trade-Offs in CI/CD Risk
CI/CD pipelines offer scale, velocity, and repeatability. They also collapse multiple trust domains into a single automation flow. The security problems that follow aren’t always obvious, emerging from the friction between autonomy and control. Here are the core tensions that matter most.
Security Ownership vs. Pipeline Autonomy
Security controls often require centralized enforcement, and that means teams can’t own their own pipelines. The more autonomy teams have, the harder it gets to ensure baseline security.
What’s the trade-off? Secure-by-design pipelines only scale when controls are embedded in the platform, and that tight control can be at odds with developer expectations.
Pipeline Observability vs. Platform Abstraction
Developers abstract everything, including containers, IaC, and ephemeral runners. But security relies on strictly documenting lineage, like what code triggered what build, deployed what container, and operates with what permissions. The more abstract the delivery system, the harder it is to attribute actions or detect drift.
Gain observability with tooling that makes up for visibility gaps in inspection. It’ll need to trace builds to identities and workloads, and operate across layers that most security tools ignore.
Speed of Automation vs. Depth of Verification
Full verification, including artifact signatures, dependency vetting, and policy checks all take time that can detract from speed. The result? There’s new pressure to defer or skip validation entirely.
Enforced policy gates are the security trade-off to consider. When security can’t get bypassed, it’s consistent and automatic. That reduces risk, but where developers are concerned, it may also create the perception of latency.
Granular Identity vs. Operational Simplicity
CI jobs, runners, and deploy scripts all need identities. The secure approach is granular., with each build job, script, or step running under a unique, scoped identity. The operationally more straightforward approach is static, shared, and persistent. It’s just easier to reuse a shared deploy token across multiple projects or environments and to give broad IAM roles rather than scoping them correctly.
Granular identity requires lifecycle management and observability. Shared identity is a liability, but often the only thing that “just works” across tools, accounts, and scripts.
Immutable Artifacts vs. Live Debugging
When things don’t change, security is easy. That’s the dream: sign once, deploy as-is. The artifact should have clear provenance, reproducibility, and easy detection of drift or tampering. But engineering teams often need to patch, test, or debug quickly, sometimes by rebuilding artifacts on the fly or bypassing gates. There isn’t always time to wait for a full rebuild.
Immutability helps with auditability and trust, but it means less flexibility when push comes to shove. Unless rollback is fast and tooling supports patch workflows, teams will route around controls when they’re facing a time crunch.
Environment Parity vs. Cost and Complexity
Security assumes parity between development, staging, and production, believing that what runs in staging is what will run in production. But keeping these phases truly identical is challenging. Many teams compromise by using limited staging data, stripped-down builds, and mocked services.
Without parity, deploy-time issues go undetected until runtime. But enforcing it often adds infrastructure overhead or slows feedback loops that CI/CD was meant to accelerate.
Centralization vs. Innovation
Security, compliance, and reliability all benefit from centralized CI/CD infrastructure. There’s one approved build system, one secrets manager, one set of policies to enforce all environments, and consistent logging, access controls, and approval workflows. However, the more standardized the pipeline, the less freedom teams have to adopt new tools or deploy models, like GitOps, serverless, or edge nodes.
Centralization brings consistency and oversight. It can also mean shadow pipelines proliferate as developers leapfrog standardization. Innovation thrives in loosely governed tooling.
Handling Trade-Offs Pragmatically
Exploring trade-offs isn’t about picking one side and maintaining absolute purity. Teams won’t fully centralize, achieve perfect parity, or rotate every secret on time. But they should treat CI/CD security as a balancing act. So even as teams consider the trade-offs that are right for their workloads, stacks, and security needs, here’s how to approach the tightrope in practice:
- Codify your minimum viable baseline: What is “secure enough”? And can this baseline be enforced across any pipeline, whether it’s fully centralized or not?
- Instrument for what’s already out there: Assume teams are using multiple CI/CD tools, and use tools that can observe them, whether registered or not. CNAPP is foundational for identifying and monitoring workloads to discover shadow pipelines or permissive tokens.
- Give developers secure defaults: Embed signed artifact generation, secrets vault injection, and IAM scoping.
- Accept trade-offs: Preventing deviations leads to friction and won’t circumvent every shadow automation or unsafe workaround. But structure the CI/CD system so that if something goes wrong, damage can’t affect unrelated systems, is traceable, and recovery is possible.
Upwind Helps Secure CI/CD Pipelines
CI/CD pipeline security requires visibility into how code, identities, artifacts, and infrastructure behave from build to runtime, across environments. Enter upwind. With runtime correlation across workloads and cloud environments, drift detection is simple. And changes aren’t just linked to pipelines, but to the identities behind them, whether they’re human or machine.
Don’t slow down the CI/CD pipeline. Make it accountable, resilient, and secure at speed. Get a demo to see how.
FAQ
What are the biggest differences in securing CI/CD across cloud providers?
Securing CI/CD across cloud providers varies due to unique architectures and tools. AWS, Azure, and GCP each have distinct identity models, secret management, and native security services that shape access controls and compliance.
Here are the key differences:
- IAM: AWS uses fine-grained roles; GCP and Azure rely more on service accounts or workload identity.
- Secrets: Vault integrations vary. AWS ties tightly to IAM, while other options require more setup.
- Artifacts: Scanning is supported, but signing and enforcement are inconsistent.
- Logging: CI/CD activity is easier to trace in AWS via CloudTrail. It’s less apparent in GCP/Azure without extra tooling.
- Runners: Execution environments differ in isolation and control.
How should we balance pipeline security with development velocity?
Balancing pipeline security with development speed means integrating automated checks — like code analysis and policy enforcement — early and continuously, catching issues before they become costly. Clear failure thresholds focus on critical risks while allowing non-blocking warnings to keep workflows smooth. Developer-friendly tools, fast feedback, and collaboration foster shared security responsibility. The goal is to embed “security as code” for fast, agile, and resilient pipelines.
What benchmarks should we use when evaluating our pipeline security?
CI/CD pipeline security benchmarks focus on traceability, containment, and control coverage across stages. It’s about making sure actions are verifiable, scoped, and observable. Look at benchmarks like:
- Artifact integrity
- Identity scoping
- Secrets exposure
- Cross-environment parity
- Blast radius
- Vulnerability count and severity
- Policy compliance
- Detection/remediation speed (MTTD and MTTR)
- False positives
- Unauthorized access attempts to assess controls
- Incident frequency
- Audit trail completeness
- Developer engagement with security feedback
How can we effectively handle false positives in automated security checks?
False positives mean less trust in security tools and slowed pipelines, so the goal is to filter noise without disabling early signals of real, severe threats. Here’s how:
- Triage with context: Utilize build-time metadata, such as asset sensitivity, to filter noise and prioritize alerts.
- Allow non-critical issues to surface: Non-critical issues should be flagged as warnings unless they exceed defined risk thresholds.
- Integrate feedback loops: This allows developers to mark known issues for review, escalate unknown issues, and track suppression.
- Correlate with runtime: Flag only exploitable issues or those in live workloads, not every theoretical CVE.
What’s the recommended first step for improving our CI/CD security posture?
Start by gaining visibility into what pipelines exist, what they’re deploying, and how they are authenticated. Inventorying all pipelines, including official CI jobs, side scripts, GitOps flows, and ad hoc deploy methods. This step is foundational because teams will never be able to secure pipelines they can’t see and haven’t mapped.
Strive to gain a real view into identity and access, artifact flow, and ungoverned paths.
