CI/CD Threats and Attacks: What Attackers Target and How to Defend

Modern software delivery relies on Continuous Integration and Continuous Delivery (CI/CD) pipelines to build, test, and deploy code at scale. These pipelines have become the backbone of DevOps, enabling organizations to ship features faster and more reliably than ever before. But this power comes with a critical trade-off: CI/CD systems have become one of the most attractive attack surfaces in enterprise environments.

Unlike traditional infrastructure, CI/CD pipelines sit at the intersection of code, credentials, and production systems. A single compromised pipeline can give an attacker everything they need — access to source code repositories, cloud credentials, signing keys, and the ability to push malicious artifacts directly into production. This is not a theoretical concern. The past five years have seen a dramatic escalation in attacks targeting software supply chains through CI/CD infrastructure, from SolarWinds to XZ Utils.

This guide provides a comprehensive taxonomy of CI/CD threats and attacks, maps them to industry frameworks like the OWASP CI/CD Top 10, walks through real-world incidents, and outlines defensive strategies you can implement today. Whether you are a security engineer, DevOps practitioner, or platform team lead, understanding these attack vectors is the first step toward building resilient pipelines.

Why Attackers Target CI/CD Pipelines

To understand the threat landscape, you need to think about CI/CD pipelines the way an attacker does. Pipelines are not just automation — they are privileged execution environments with unique properties that make them extraordinarily valuable targets.

Privileged Access to Everything

CI/CD pipelines routinely hold credentials to cloud providers (AWS, GCP, Azure), container registries, package repositories, databases, and production Kubernetes clusters. A single pipeline runner often has more access than any individual developer. Attackers who compromise a pipeline inherit all of these privileges instantly.

Automation as a Weapon

Pipelines are designed to execute code automatically in response to triggers — a push to a branch, a pull request, a tag, or a scheduled cron. This automation, which is the entire point of CI/CD, becomes a weapon when an attacker can influence what gets executed. Unlike a human reviewer, a pipeline will faithfully run whatever instructions it is given, including malicious ones.

Implicit Trust Assumptions

Most CI/CD architectures are built on a foundation of implicit trust. Organizations trust that pipeline configuration files have not been tampered with. They trust that dependencies resolved during build time are legitimate. They trust that third-party GitHub Actions or shared pipeline templates are safe. Each of these trust assumptions represents a potential attack vector.

Weak Security Posture

CI/CD systems often exist in a security blind spot. They are managed by engineering teams rather than security teams, they lack the monitoring and logging that production systems receive, and they accumulate technical debt in the form of overly permissive configurations, stale credentials, and unpatched runners. This makes them soft targets relative to hardened production infrastructure.

Supply Chain Amplification

Perhaps the most dangerous aspect of CI/CD attacks is their amplification potential. Compromising a single pipeline that builds a widely-used library or service can propagate malicious code to thousands or millions of downstream consumers. This supply chain amplification effect is what makes incidents like SolarWinds and XZ Utils so devastating.

CI/CD Attack Taxonomy: Mapping to the OWASP CI/CD Top 10

The OWASP CI/CD Top 10 provides a structured framework for understanding the most critical risks in CI/CD environments. Each risk category represents a class of attack vectors that adversaries actively exploit. Here is how the major attack types map to this framework:

OWASP CI/CD Risk	Attack Category	Key Concern
CICD-SEC-1	Insufficient Flow Control	Missing approvals, no branch protection
CICD-SEC-2	Inadequate Identity and Access Management	Overly permissive service accounts
CICD-SEC-3	Dependency Chain Abuse	Dependency confusion, typosquatting
CICD-SEC-4	Poisoned Pipeline Execution	Malicious pipeline config in PRs/branches
CICD-SEC-5	Insufficient PBAC	Pipeline-Based Access Controls missing
CICD-SEC-6	Insufficient Credential Hygiene	Hardcoded secrets, unrotated tokens
CICD-SEC-7	Insecure System Configuration	Default configs, unpatched CI servers
CICD-SEC-8	Ungoverned Use of Third-Party Services	Compromised Actions, unvetted integrations
CICD-SEC-9	Improper Artifact Integrity Validation	Unsigned artifacts, tag mutation
CICD-SEC-10	Insufficient Logging and Visibility	No audit trail, blind spots in monitoring

For a deep dive into each of these risks with real-world examples, see our detailed guide: OWASP Top 10 CI/CD Risks Explained with Real-World Examples.

The sections below explore the most impactful attack categories in detail, examining the mechanics, real-world examples, and detection strategies for each.

Poisoned Pipeline Execution (PPE)

Poisoned Pipeline Execution (PPE) is one of the most dangerous and prevalent classes of CI/CD attacks. It occurs when an attacker manipulates the CI/CD pipeline configuration or build instructions to execute malicious code within the pipeline environment. The attack leverages the fact that pipelines automatically execute instructions defined in configuration files — and those files can often be modified by contributors.

Direct PPE (D-PPE)

In Direct PPE, the attacker has write access to the repository and directly modifies the pipeline configuration file (e.g., .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, or azure-pipelines.yml). The attacker injects malicious steps that run with the full privileges of the pipeline. This could include exfiltrating secrets, injecting backdoors into build artifacts, or establishing persistence in the CI/CD environment.

D-PPE is particularly effective when:

• Branch protection rules are weak or absent
• Pipeline runs trigger on push events to any branch
• Self-hosted runners with persistent state are used
• CODEOWNERS files do not protect pipeline configuration

Indirect PPE (I-PPE)

Indirect PPE is more subtle and harder to detect. Instead of modifying the pipeline configuration directly, the attacker modifies files that the pipeline consumes during execution. This includes:

• Build scripts referenced in the pipeline (e.g., Makefile, build.sh, package.json scripts)
• Dependency manifests that pull in malicious packages during build
• Configuration files consumed by build tools (e.g., .npmrc, setup.py, build.gradle)
• Test fixtures or data files that are processed by pipeline steps

I-PPE is especially dangerous because code review processes typically focus on application code changes, not on the security implications of modified build scripts or dependency files. An attacker can hide malicious instructions in a seemingly innocent change to a Makefile that gets executed with full pipeline privileges.

PPE via Pull Requests

Many CI/CD systems are configured to run pipelines on pull requests from forks — a necessary feature for open-source projects. However, this creates a direct attack vector: an external contributor can submit a pull request that modifies the pipeline configuration or build scripts, and the pipeline will execute the malicious code before any human review occurs. While some platforms restrict secret access for fork PRs, misconfigurations frequently expose secrets or the pipeline environment itself provides sufficient value to the attacker.

To explore PPE attack techniques hands-on and learn defensive countermeasures, work through our dedicated lab: Lab: Exploiting and Defending Against Poisoned Pipeline Execution (PPE).

Dependency Confusion and Artifact Poisoning

Dependency confusion and artifact poisoning attacks exploit the trust that build systems place in package registries and dependency resolution mechanisms. These attacks target the supply chain at its most fundamental level — the components that get pulled into your software during build time.

Dependency Confusion

Dependency confusion (also called namespace confusion or substitution attacks) exploits the way package managers resolve dependencies when both public and private registries are configured. The attacker publishes a malicious package to a public registry (npm, PyPI, RubyGems) using the same name as an internal/private package used by the target organization. If the package manager is not configured to prioritize the private registry, it may pull the malicious public version instead — especially if the attacker publishes a higher version number.

This attack was famously demonstrated by security researcher Alex Birsan in 2021, who used dependency confusion to execute code within the build systems of Apple, Microsoft, PayPal, and dozens of other major organizations. The attack required no access to the target organization — only knowledge of internal package names, which can sometimes be discovered through leaked lock files, JavaScript source maps, or error messages.

Typosquatting

Related to dependency confusion, typosquatting involves publishing malicious packages with names that are very similar to popular legitimate packages (e.g., lodahs instead of lodash, reqeusts instead of requests). When a developer or build script makes a typo in a dependency declaration, the malicious package is installed instead.

Artifact Poisoning

Artifact poisoning takes a different approach, targeting the artifacts produced by build pipelines rather than their inputs. Attackers who gain access to artifact storage (container registries, package repositories, binary storage) can replace legitimate artifacts with backdoored versions. This is particularly effective against container images stored in registries with mutable tags — an attacker who gains write access can replace the image behind a :latest or :v1.2.3 tag without changing the tag itself.

For a thorough exploration of these attack vectors and their defenses, see: Dependency Confusion and Artifact Poisoning: Attacks and Defenses.

Credential Theft and Secret Exfiltration

CI/CD pipelines are treasure troves of credentials. They need access to source code repositories, cloud providers, container registries, databases, deployment targets, and external services. These credentials — API keys, tokens, passwords, certificates, and signing keys — are the primary target for many CI/CD attacks.

Common Secret Exfiltration Techniques

Attackers use a variety of techniques to steal secrets from CI/CD environments:

• Environment variable dumping: Many CI/CD systems inject secrets as environment variables. A simple env or printenv command in a compromised pipeline step reveals all available secrets.
• File system scanning: Secrets may be written to disk as files (e.g., ~/.docker/config.json, ~/.aws/credentials, ~/.kube/config). Attackers scan the file system for credential files.
• Memory inspection: On self-hosted runners, attackers can inspect process memory or /proc to find secrets that were decrypted at runtime.
• Network interception: If pipelines communicate with services over unencrypted channels, attackers with network access can intercept credentials in transit.
• Log exfiltration: Secrets that accidentally appear in build logs (a depressingly common occurrence) can be extracted by anyone with log access.
• DNS/HTTP exfiltration: In restricted environments where outbound connections are limited, attackers encode stolen secrets in DNS queries or HTTP headers to bypass egress controls.

The Compounding Problem of Credential Sprawl

A key challenge in CI/CD security is credential sprawl — the tendency for secrets to accumulate over time across pipeline configurations, environment variables, secret stores, and configuration files. Long-lived credentials that are never rotated, overly permissive service accounts, and secrets shared across multiple pipelines all increase the blast radius of a credential theft incident.

The solution is a disciplined approach to secrets management that combines short-lived credentials, least-privilege access, secret rotation, and runtime injection from a centralized vault. For detailed implementation guidance, see our guide on Secrets Management in CI/CD Pipelines: Patterns with Vault.

To practice detecting and preventing secret leaks in a controlled environment, work through our hands-on lab: Lab: Detecting and Preventing Secret Leaks in CI/CD Pipelines.

Artifact Tampering and Registry Attacks

Artifact integrity is a cornerstone of supply chain security. If an attacker can modify the artifacts that your pipeline produces — container images, packages, binaries, or deployment manifests — they can inject malicious code that propagates to every environment that consumes those artifacts.

Tag Mutation Attacks

Container registries allow image tags to be overwritten by default. An attacker with write access to a registry can replace the image behind any mutable tag (such as :latest, :stable, or even a seemingly specific version tag like :v2.1.0) with a backdoored version. Downstream systems pulling that tag will silently receive the compromised image.

This is why immutable tags and digest-based references (image@sha256:abc123...) are critical security controls. Content trust mechanisms like Docker Content Trust (DCT) and Sigstore/cosign provide cryptographic verification of image provenance.

Registry Compromise

Direct compromise of artifact registries — whether through stolen credentials, exploitation of registry vulnerabilities, or insider threats — gives attackers the ability to modify any stored artifact. Self-hosted registries that lack authentication, use default credentials, or run unpatched software are particularly vulnerable.

Build Process Manipulation

Rather than tampering with artifacts after they are built, sophisticated attackers modify the build process itself to produce compromised artifacts. This can involve manipulating Dockerfiles, injecting malicious layers into multi-stage builds, or modifying compilation flags to insert backdoors. These attacks are particularly insidious because the resulting artifacts appear to be legitimate products of the CI/CD pipeline.

Defending against artifact tampering requires a combination of immutable storage, cryptographic signing, provenance attestation (such as SLSA), and continuous verification. To practice detecting artifact tampering in a hands-on environment, see: Lab: Artifact Tampering Detection — Swapping Container Images in a Registry.

Compromised Third-Party Actions and Integrations

Modern CI/CD pipelines are not monolithic — they are assembled from dozens of third-party components: GitHub Actions, GitLab CI templates, Jenkins plugins, Terraform providers, and various SaaS integrations. Each of these components represents a trust boundary that attackers can exploit.

GitHub Actions Supply Chain Attacks

GitHub Actions are a prime target because they execute arbitrary code within the context of the workflow that calls them. Attack vectors include:

• Compromised action repositories: An attacker who gains access to a popular action’s repository can push malicious code that executes in every workflow using that action. The tj-actions/changed-files incident in 2023 demonstrated this at scale.
• Tag manipulation: Actions referenced by mutable tags (e.g., @v3) can be silently replaced. The attacker moves the tag to point to a malicious commit.
• Typosquatting: Malicious actions published under names similar to popular ones exploit developer typos.
• Abandoned action takeover: When action maintainers abandon their projects, attackers can sometimes claim the namespace and push malicious updates.

Plugin and Extension Risks

Jenkins plugins, GitLab CI components, and other CI/CD extensions face similar risks. Many plugins are maintained by individual contributors with varying security practices. Vulnerabilities in plugins can expose the entire CI/CD infrastructure, as Jenkins plugins have historically been a rich source of credential theft and remote code execution vulnerabilities.

The defensive strategy is to pin all third-party components to immutable references (commit SHAs rather than tags), regularly audit dependencies, and use tools that detect known-malicious actions. For hands-on practice with detecting malicious GitHub Actions, work through: Lab: Detecting Malicious GitHub Actions with Static Analysis.

Real-World CI/CD Attack Timeline

The following timeline tracks major CI/CD and software supply chain attacks from 2020 to 2024. Each incident illustrates different attack vectors and reinforces why CI/CD security deserves dedicated attention.

SolarWinds / SUNBURST (December 2020)

The SolarWinds attack remains the defining CI/CD supply chain compromise. Attackers (attributed to Russia’s SVR intelligence service) infiltrated SolarWinds’ build infrastructure and injected the SUNBURST backdoor into the Orion software update process. The compromised build pipeline produced trojanized updates that were distributed to approximately 18,000 organizations, including US government agencies, Fortune 500 companies, and critical infrastructure operators.

Key lessons: Build infrastructure must be treated as a critical asset. Artifact integrity verification and reproducible builds could have detected the tampering. The attack demonstrated that compromising a single build pipeline can have nation-state-level impact.

Codecov Bash Uploader (January–April 2021)

Attackers compromised Codecov’s Bash Uploader script — a component used by thousands of CI/CD pipelines to upload code coverage reports. For three months, the modified script exfiltrated environment variables (including CI/CD secrets, tokens, and keys) from every pipeline that executed it. The attack affected companies including Twitch, HashiCorp, Confluent, and many others.

Key lessons: Third-party scripts executed in pipelines must be integrity-verified (e.g., via checksums). Secrets should never be broadly available as environment variables. Egress monitoring on CI/CD runners could have detected the exfiltration.

ua-parser-js Hijack (October 2021)

The npm package ua-parser-js, downloaded 7+ million times per week, was hijacked when the maintainer’s npm account was compromised. Malicious versions were published that installed cryptominers and credential-stealing malware. Because this package is a dependency of thousands of other packages and CI/CD build processes, the blast radius was enormous.

Key lessons: Even trusted, widely-used packages can be compromised. Lock files, integrity checking, and automated dependency scanning in CI/CD are essential. npm account security (2FA, token scoping) is a supply chain concern.

CircleCI Security Incident (January 2023)

CircleCI, one of the largest CI/CD platforms, disclosed that an attacker had gained access to customer data including environment variables, keys, and tokens stored in CircleCI. The breach originated from malware on an engineer’s laptop that stole a valid SSO session token, which was then used to access internal systems. CircleCI urged all customers to immediately rotate every secret stored in the platform.

Key lessons: CI/CD platform providers are high-value targets. Organizations should implement defense-in-depth and not rely solely on their CI/CD platform’s security. Short-lived, scoped credentials limit the impact of platform compromises. Having an incident response plan for secret rotation is critical.

tj-actions/changed-files Compromise (March 2023)

The popular GitHub Action tj-actions/changed-files (used by over 23,000 repositories) was compromised when an attacker gained access to the maintainer’s account and pushed malicious code. The compromised action dumped CI/CD secrets to workflow logs, where they could be harvested. Because many workflows referenced the action using mutable version tags, the malicious code was automatically pulled into thousands of pipeline runs.

Key lessons: Always pin GitHub Actions to commit SHAs, not version tags. Monitor action dependencies for unexpected changes. Implement workflow permissions following the principle of least privilege.

XZ Utils Backdoor (March 2024)

The XZ Utils backdoor (CVE-2024-3094) was a sophisticated, multi-year supply chain attack. A contributor who had built trust within the XZ project over two years gradually introduced a backdoor into the build system. The malicious code was hidden in test fixture files and activated through carefully crafted build scripts — a textbook example of Indirect Poisoned Pipeline Execution. The backdoor targeted the SSH daemon on Linux systems and would have affected virtually every Linux distribution if not discovered by chance.

Key lessons: Social engineering and long-term infiltration of open-source projects are real threats. Build system integrity is as important as source code integrity. The attack demonstrated that I-PPE techniques can be extraordinarily subtle and patient.

Defensive Patterns and Mitigations

Defending against CI/CD attacks requires a layered approach that addresses each attack category. The following patterns form the foundation of a robust CI/CD security posture.

Pipeline Configuration as Code with Strict Controls

• Protect pipeline configuration files with CODEOWNERS and branch protection rules
• Require code review for all changes to CI/CD configuration
• Use centrally managed pipeline templates rather than per-repo configurations where possible
• Separate pipeline definitions from application code in sensitive repositories

Credential Hardening

• Use short-lived, scoped credentials (OIDC federation with cloud providers)
• Implement just-in-time secret injection from a centralized vault
• Never expose secrets as environment variables when file-based injection is available
• Rotate all credentials on a defined schedule and immediately after any incident
• Implement secret scanning in CI/CD logs and artifact outputs

Dependency and Supply Chain Controls

• Pin all dependencies to exact versions with integrity hashes
• Use private registry proxies with namespace scoping to prevent dependency confusion
• Pin GitHub Actions and other third-party pipeline components to commit SHAs
• Implement automated dependency vulnerability scanning in every pipeline
• Generate and verify Software Bills of Materials (SBOMs)

Artifact Integrity

• Sign all build artifacts cryptographically (Sigstore/cosign for containers, GPG for packages)
• Use immutable tags and digest-based references for container images
• Implement SLSA provenance attestation to verify artifact origin
• Deploy admission controllers (e.g., Kyverno, OPA Gatekeeper) that verify signatures before deployment

Monitoring and Detection

• Monitor pipeline execution for anomalous behavior (unexpected network connections, file system access, long-running jobs)
• Implement egress controls on CI/CD runners to detect exfiltration
• Audit all changes to pipeline configurations, secrets, and permissions
• Correlate CI/CD events with SIEM for cross-system detection

For a comprehensive deep dive into each of these defensive patterns with implementation examples, see: Defensive Patterns and Mitigations for CI/CD Pipeline Attacks.

Threat Modeling for CI/CD

Effective CI/CD security starts with threat modeling — systematically identifying trust boundaries, data flows, and attack paths within your pipeline architecture. Without a clear understanding of your CI/CD threat model, defensive efforts tend to be reactive and incomplete.

Key Trust Boundaries to Evaluate

Every CI/CD system has trust boundaries that attackers attempt to cross:

• Developer workstation to repository: Can a compromised developer machine push malicious code?
• Repository to pipeline: What changes trigger pipeline execution, and with what privileges?
• Pipeline to secrets store: Which pipelines can access which secrets, and under what conditions?
• Pipeline to artifact registry: Who can push artifacts, and are they verified before use?
• Artifact registry to deployment: Are deployed artifacts verified against their build provenance?
• Third-party services to pipeline: What access do external integrations have?

Attack Path Analysis

Once trust boundaries are mapped, the next step is to enumerate attack paths — the sequences of actions an attacker could take to achieve their objectives. Common objectives include:

• Injecting malicious code into production deployments
• Exfiltrating credentials for lateral movement
• Establishing persistence in the CI/CD infrastructure
• Disrupting software delivery (sabotage/denial of service)
• Compromising downstream consumers through supply chain propagation

For a complete guide to CI/CD threat modeling with practical frameworks and templates, see: CI/CD Threat Modeling: Trust Boundaries and Attack Paths.

Hands-On Labs: Practice Attack and Defense

Understanding CI/CD attacks in theory is important, but there is no substitute for hands-on practice. The following labs provide controlled environments where you can safely explore attack techniques and implement defenses:

• Lab: Exploiting and Defending Against Poisoned Pipeline Execution (PPE) — Practice both Direct and Indirect PPE attacks, then implement branch protection, CODEOWNERS, and pipeline configuration controls to defend against them.
• Lab: Dependency Confusion and Artifact Poisoning — Execute a dependency confusion attack against a vulnerable build configuration, then implement namespace scoping, integrity verification, and private registry controls.
• Lab: Detecting and Preventing Secret Leaks in CI/CD Pipelines — Discover secrets exposed through environment variables, logs, and artifacts, then implement detection with tools like gitleaks, truffleHog, and custom pipeline guards.
• Lab: Artifact Tampering Detection — Swapping Container Images in a Registry — Perform a tag mutation attack against a container registry, then implement content trust, digest pinning, and admission controller verification.
• Lab: Detecting Malicious GitHub Actions with Static Analysis — Analyze GitHub Actions for malicious patterns, implement SHA pinning, and build automated detection into your workflow approval process.

Each lab includes step-by-step instructions, a pre-configured environment, and both attack and defense scenarios. They are designed to be completed independently, though working through them in the order listed above will build a comprehensive understanding of CI/CD security.

Conclusion: Building a Defensible CI/CD Architecture

CI/CD pipelines have become the most consequential attack surface in modern software organizations. The incidents catalogued in this guide — from SolarWinds to XZ Utils — demonstrate that attackers have recognized this reality and are investing significant resources in CI/CD exploitation techniques.

But the picture is not entirely bleak. The CI/CD security community has responded with frameworks (OWASP CI/CD Top 10, SLSA), tools (Sigstore, gitleaks, StepSecurity), and architectural patterns that can dramatically reduce your exposure. The key principles to remember are:

1. Treat pipelines as production infrastructure. Apply the same security rigor to CI/CD that you apply to production systems: least-privilege access, monitoring, patching, and incident response.
2. Eliminate implicit trust. Verify everything — dependencies, third-party actions, artifacts, and pipeline configurations. Pin to immutable references. Sign and verify at every stage.
3. Minimize the blast radius. Use short-lived credentials, scoped permissions, isolated runners, and network segmentation to limit what an attacker can achieve from any single compromise.
4. Invest in visibility. You cannot defend what you cannot see. Comprehensive logging, monitoring, and alerting for CI/CD systems are non-negotiable.
5. Practice your response. Use the labs linked throughout this guide to build muscle memory for both attack detection and defense implementation. When the next CI/CD incident hits, you will be ready.

CI/CD security is not a one-time project — it is an ongoing discipline that must evolve as attack techniques advance. Start with a threat model, implement the defensive patterns that address your highest risks, and continuously validate your defenses through the hands-on labs above. Your pipelines are too important to leave undefended.