CI/CD Pipeline Security Best Practices 2026

CI/CD security risks and why they matter

CI/CD security focuses on protecting the systems that build, test, and deploy your code. These pipelines control access to source code, secrets, artifacts, and production environments, which makes them one of the highest-impact attack surfaces in modern software delivery.

A compromise here doesn’t stay contained. Attackers can inject malicious code into builds, extract credentials from pipeline configurations, or move laterally into production systems. Because pipelines automate distribution, a single breach can propagate across environments and reach customers before anyone notices. Rapid CI/CD delivery amplifies both impact and exposure.

CI/CD Best Practices [Cheat Sheet]

This comprehensive guide provides you with actionable best practices to mitigate CI/CD security risks.

Your work email here

Download

The OWASP Top 10 CI/CD Security Risks framework highlights where these failures typically occur:

• CICD-SEC-1: Insufficient flow control mechanisms: Pipelines lack enforcement gates, allowing untrusted code or artifacts to progress unchecked

• CICD-SEC-2: Inadequate identity and access management: Overprivileged users and service accounts enable unauthorized changes

• CICD-SEC-6: Insufficient credential hygiene: Hardcoded or long-lived secrets expose pipelines to takeover

• CICD-SEC-9: Improper artifact integrity validation: Unsigned or unverified artifacts allow tampering in transit

These risks are not theoretical. They reflect how real CI/CD breaches happen—through weak controls, not complex exploits.

Components at risk

Every part of the pipeline introduces a specific attack surface:

• Source code repositories: Exposed to credential theft and unauthorized commits

• Build servers and workers: Vulnerable to code injection and dependency confusion

• Artifact repositories: Targets for poisoned packages and artifact substitution

• Deployment environments: Exposed through misconfigured permissions and weak credentials

• CI runners: Often overprivileged, enabling lateral movement across projects

• Orchestration tools: Exploitable for modifying deployments or redirecting traffic

Each component becomes a pivot point if controls are weak. If one fails, attackers can move downstream quickly.

Challenges in CI/CD security

Securing pipelines is difficult because the risks compound:

• Complexity: Interconnected tools create a broad and hard-to-map attack surface

• Speed vs. security tension: Rapid releases reduce time for manual validation

• Automation gaps: Missing checks allow vulnerabilities to scale instantly

• Access control at scale: Managing least privilege across teams and services is ongoing work

• Secrets sprawl: Credentials spread across configs, environments, and integrations

• Supply chain exposure: Dependency confusion, typosquatting, and unpinned versions introduce malicious code

• Unvetted third-party actions: Reusable CI templates and plugins can introduce backdoors if not pinned and reviewed

• AI-driven development and velocity: The use of AI coding assistants accelerates development but also increases the risk of hallucinated dependencies and insecure code patterns entering the pipeline at a rate manual reviews cannot keep up with.

These challenges highlight why CI/CD security breaks down and why controls need to be consistent, automated, and enforced across every stage.

Catch code risks before you deploy

Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

The different types of CI/CD pipelines

Pipeline architecture directly shapes your security posture. Each model changes where trust lives, how access is controlled, and how risks propagate. 

A control that works in one setup may fail in another, which is why security needs to align with how your pipeline is structured—especially for teams still running traditional CI servers like Jenkins, where plugin governance and build node isolation remain critical.

GitOps pipelines

Git becomes the control plane, which makes it a high-value target and single point of compromise. If repository access is too permissive or commits are not verified, attackers can push malicious changes directly into production.

Strong controls start in the repo. Enforce signed commits, apply strict branch protection, and require approvals before changes deploy. Pair this with drift detection so unauthorized changes surface quickly.

Container-based pipelines

Container pipelines introduce risk through image provenance and build environment integrity. Compromised base images or poisoned dependencies can flow into production through otherwise valid builds.

Control comes from verifying what you build and where it runs. Use image signing and scanning, avoid privileged containers, and rely on ephemeral build environments that reset after each job. Harden base images and lock down registry access.

Serverless pipelines

Serverless pipelines shift risk into identity and execution boundaries. Overly broad IAM roles or unvalidated event triggers can allow attackers to escalate privileges or execute unauthorized workflows.

The fix comes from tightening control over execution context. Scope IAM roles narrowly, validate event sources, and ensure centralized logging. Ephemeral environments make visibility harder, so logs need to be structured and aggregated.

Hybrid pipelines

Hybrid pipelines combine multiple models, which creates inconsistent policy enforcement and fragmented visibility. Weak controls in one segment can undermine stronger controls elsewhere.

Mitigate this by enforcing consistent policies across environments, securing credential exchange between on-prem and cloud systems, and implementing network segmentation between pipeline components. Centralized logging and monitoring are critical to maintain visibility across the entire workflow.

Security at each pipeline stage

CI/CD pipelines have four connected stages, each with distinct security controls and risks. Each stage acts as a gate, where failures can allow vulnerabilities to move closer to production.

Embed security gates at each transition point so code cannot progress without passing required validation controls.

CI/CD pipeline security best practices

CI/CD pipelines fail when security controls are inconsistent or easy to bypass. 

The following practices reduce real attack paths while maintaining delivery speed.

Automating security scanning across the pipeline

Unscanned code, dependencies, and infrastructure allow vulnerabilities to move through the pipeline and reach production.

Reduce this risk by embedding automated scanning at every stage:

• SAST identifies code-level vulnerabilities during development

• SCA detects vulnerable dependencies during the build stage

• DAST uncovers runtime vulnerabilities in deployed applications

• IaC scanning catches infrastructure misconfigurations before provisioning

While standalone scanners like SAST and SCA are essential, running them in silos often leads to massive alert fatigue. For security teams, the challenge isn't just finding vulnerabilities, but knowing which ones actually matter. To be effective, organizations should adopt an Application Security Posture Management (ASPM) approach that aggregates, de-duplicates, and prioritizes these findings based on actual cloud context—like whether a vulnerable package is actually reachable from the internet.

Tools like Semgrep, Snyk, Checkov, and SonarQube integrate directly into CI/CD workflows.

# Example of SonarQube integration in a Jenkins pipeline
pipeline {
    agent any
    stages {
        stage('SonarQube Analysis') {
            steps {
                script {
                    def scannerHome = tool 'SonarQube Scanner';
                    withSonarQubeEnv('My SonarQube Server') {
                        sh "${scannerHome}/bin/sonar-scanner"
                    }
                }
            }
        }
    }
}

Extend security into runtime

Pipeline security does not stop at deployment. Without runtime visibility, attackers can exploit gaps that static checks miss.

Apply the following runtime security protocol:

1. Centralize and monitor pipeline activity by integrating logs into SIEM or SOAR platforms to detect suspicious behavior and trigger automated responses.

2. Detect anomalous behavior by establishing baselines and flagging unusual patterns such as off-hours commits or unexpected configuration changes.

3. Deploy cloud-native runtime sensors: Supplement traditional logging with lightweight sensors like eBPF. This provides deep, real-time visibility into system calls, file integrity, and network activity with minimal overhead, allowing you to catch threats that static analysis might miss.

4. Protect sensitive data in logs by avoiding the capture of secrets and using structured formats like JSON for secure, parseable logging.

5. Prepare and automate response actions with defined incident playbooks and automated containment to isolate compromised builds before they reach production.

Tools like Splunk, Datadog, or IBM QRadar support centralized logging, detection, and response across CI/CD environments.

Manage secrets with zero hardcoded credentials

Exposed credentials remain one of the most common causes of CI/CD breaches, often due to weak or inconsistent secrets management practices.

Prevent this by removing secrets from code, configuration files, and artifacts entirely. Store credentials in centralized vaults such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, and inject them only at runtime.

Effective secrets management requires:

• Centralized storage: Store credentials in a secure vault with audit logging and access controls  

• Runtime injection: Inject secrets only when needed—never bake them into images or artifacts  

• Pre-commit scanning: Block credentials from entering repositories using tools like git-secrets or TruffleHog  

• Automated rotation: Rotate secrets automatically to reduce exposure windows if credentials leak 

Implement immutable infrastructure

Mutable environments allow attackers to persist changes and introduce hidden backdoors. Adopt immutable infrastructure so environments are rebuilt from trusted definitions rather than modified in place. This removes configuration drift, prevents persistent backdoors in build environments, and ensures deployments are reproducible.

Use Infrastructure as Code (IaC) with validation controls to enforce consistency. Pair this with drift detection to identify unauthorized changes and maintain a clean deployment state. Then, use IaC scanning tools to validate infrastructure definitions before deployment and prevent insecure configurations from reaching production.

Enforce least privilege with RBAC and SCM hardening

Overprivileged access and weak repository controls allow attackers to modify pipelines, bypass approval gates, or escalate privileges.

Reduce this risk by enforcing least privilege across users, service accounts, and pipeline components. Scope permissions tightly, limit who can merge to protected branches, and secure automation accounts with credential rotation and network restrictions.

Harden source code management alongside role-based access controls:

• Require signed commits: Verify commits come from authenticated developers using GPG or SSH signing  

• Enforce MFA: Require multi-factor authentication for all CI/CD system access  

• Configure branch protection: Require pull request reviews, status checks, and restrict force pushes to protected branches  

• Disable auto-merge: Prevent automated merges without human review for production-bound changes  

• Audit with Legitify: Continuously assess SCM configuration against security benchmarks  

Apply the four-eyes principle for critical operations by requiring independent approvals for production deployments so no single person controls the release process.

Build a security culture through training

Security controls fail when teams do not understand how to apply them.

Build security into development workflows by training engineers to identify risks early. Establish security champions within teams and introduce controls incrementally using a “controlled shift-left” approach. Run practical exercises such as quarterly pipeline threat modeling sessions to reinforce real-world scenarios and improve response readiness.

CI/CD security: What are your responsibilities?

Cloud providers do not secure your CI/CD pipelines. The shared responsibility model places pipeline security within your organization’s control.

Providers are responsible for securing the underlying infrastructure, including physical data centers, platform availability, and core service maintenance. They ensure the platform runs securely—but not how you use it.

Your organization is responsible for everything built on top of that foundation. This includes configuring pipelines securely, managing access and identities, protecting secrets, validating code and dependencies, and monitoring for threats. If a breach occurs due to a misconfigured GitHub Actions workflow or an exposed Jenkins credential, the responsibility remains with you.

This distinction is critical. CI/CD security failures rarely come from the platform itself—they come from misconfigurations, overprivileged access, and exposed credentials within the pipeline.

What are the components of CI/CD security?

A CI/CD security strategy relies on multiple controls applied across the pipeline. 

The table below provides a quick reference to the core components and where they apply:

Measuring CI/CD pipeline security effectiveness

To improve CI/CD security, teams need consistent visibility into how controls perform over time. Track the following key performance indicators (KPIs) to measure effectiveness and identify gaps:

• Vulnerability detection rate: Measures how effectively security tools identify issues compared to total vulnerabilities present. Establish a baseline using periodic penetration testing, then compare detection rates across tools to identify blind spots.
  Target: Detection rates should increase over time as coverage improves.

• Mean time to remediate (MTTR): Tracks how quickly teams resolve security issues after detection. Use ticketing systems with automated timestamps to measure resolution time and break down by severity.
  Target: MTTR should decrease quarter over quarter, especially for high-severity vulnerabilities.

• Pipeline security policy compliance rate: Measures the percentage of pipelines that meet defined security standards. Implement policy-as-code and integrate automated checks into CI/CD workflows to track compliance.
  Target: Compliance should trend toward full coverage, with minimal policy violations.

• Security test coverage: Assesses how much of your codebase and infrastructure is evaluated by security controls. Aggregate coverage data across SAST, DAST, SCA, and IaC scanning tools, and map it against your threat model.
  Target: Coverage should expand across critical systems and high-risk components.

• Failed build rate due to security issues: Indicates how often security controls block builds. Track security-related failures separately from functional ones to measure enforcement effectiveness.
  Target: Expect an initial increase as controls are enforced, followed by a decline as teams address root causes.

Aggregate these metrics in a SIEM, DevSecOps dashboard, or reporting platform to monitor trends, identify regressions, and guide remediation priorities.

Wiz's approach to CI/CD security

Latio’s 2026 Application Security Report awarded Wiz four badges, validating a lifecycle approach that secures everything from initial commit to runtime.

Wiz Code connects application security directly to your cloud environment. By correlating IaC misconfigurations, code vulnerabilities, and cloud risk signals through the Wiz Security Graph, teams can prioritize what is actually exploitable rather than chasing every finding.

This approach maps directly to the controls outlined above. Wiz automates security scanning across code, dependencies, and infrastructure, extends visibility into runtime environments, and identifies exposed secrets and misconfigurations before they can be exploited.

For CI/CD pipelines, Wiz provides:

• Unified pipeline integration: Native connectors for Jenkins, GitLab, GitHub Actions, and CircleCI embed security checks without disrupting workflows

• Shift-left vulnerability detection: Identify risks in code, infrastructure definitions, and dependencies early in the pipeline

• Code-to-cloud correlation: Trace vulnerabilities from source through build artifacts to running workloads for faster, prioritized remediation

As development teams adopt AI-driven workflows, Wiz extends this model to secure AI pipelines and model training environments using the same graph-based approach.

Get a demo to view unified visibility across your software delivery process, or download the CI/CD Security Best Practices Cheat Sheet to secure every stage of your pipeline.

Secure your workloads, from build-time to run-time

See why Wiz is one of the few cloud security platforms that security and devops teams both love to use.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

FAQs about CI/CD pipeline security