Why modern attackers increasingly target your build pipeline instead of your application

Introduction

When organizations discuss security, most conversations revolve around production environments.

Teams harden Kubernetes clusters, deploy Web Application Firewalls, configure endpoint detection systems, implement zero-trust networking, and perform penetration tests against customer-facing applications.

Meanwhile, one of the most privileged systems in the organization often receives only a fraction of that attention:

The CI/CD pipeline.

Modern attackers have realized something important:

Why attack a heavily monitored production environment when you can compromise the mechanism responsible for building and deploying it?

A successful CI/CD compromise can grant attackers access to source code, cloud infrastructure, deployment systems, signing keys, software supply chains, and every environment the pipeline touches.

In many organizations, CI/CD is not merely another system. It is the trust engine that powers software delivery. And increasingly, it has become one of the most attractive targets for attackers.

CI/CD Is a Trust Transformation System

Most discussions about CI/CD focus on automation and developer productivity. From a security perspective, however, CI/CD serves a much more critical role.

A pipeline transforms untrusted source code into trusted deployable artifacts.

Every deployment depends on a chain of trust:

Developer → Source Repository → Build Pipeline → Artifact Repository → Deployment Platform → Production

The moment a pipeline successfully completes, organizations generally assume that the resulting artifact is safe to deploy. This assumption creates a powerful trust boundary.

Attackers understand that compromising a build pipeline allows them to manipulate that trust boundary itself. Rather than attacking production directly, they attack the system responsible for determining what reaches production.

The Dangerous Level of Trust in CI/CD

Consider what a typical CI/CD pipeline can access:

• Source code repositories
• Cloud deployment credentials
• Kubernetes clusters
• Infrastructure-as-Code repositories
• Production deployment permissions
• Artifact signing systems
• Secrets management platforms
• Internal package repositories
• Third-party SaaS integrations

A compromised developer workstation may affect one engineer. A compromised CI/CD runner can affect an entire organization.

In many environments, the CI/CD platform possesses privileges that exceed those of most employees, administrators, and even some security teams.

Yet many organizations continue treating CI/CD as a development tool rather than a critical security boundary.

Why Attackers Love CI/CD Systems

1. Massive Privilege Concentration

A single pipeline execution may have access to:

• Production cloud accounts
• Kubernetes administration privileges
• GitHub write permissions
• Artifact signing keys
• Automated deployment systems

Compromising one build process can provide access to multiple trust domains simultaneously. For attackers, few systems offer such a high return on investment.

2. Implicit Organizational Trust

Organizations naturally trust artifacts produced by their build systems.

If Jenkins, GitHub Actions, GitLab CI, Azure DevOps, or Buildkite produces a release artifact, most teams assume it is legitimate.

Attackers exploit this trust.

Rather than bypassing security controls in production, they position themselves upstream and allow organizations to deploy malicious code on their behalf.

3. Limited Visibility

Security teams often invest heavily in monitoring:

• Endpoints
• Servers
• Containers
• Production workloads
• Network traffic

Far fewer organizations monitor:

• Pipeline modifications
• Workflow execution
• Secret access patterns
• Runner behavior
• Build-time network activity

This creates a highly attractive blind spot.

Real-World Supply Chain Attacks

Several major incidents demonstrate why CI/CD systems have become prime targets.

SolarWinds

The SolarWinds Supply Chain Attack remains one of the most significant examples of build pipeline compromise.

Attackers infiltrated the software build process and inserted malicious code into trusted software updates. Customers unknowingly installed compromised updates signed and distributed through legitimate channels.

The attackers weaponized trust itself.

Codecov

The Codecov Bash Uploader Breach demonstrated how even a small modification to a CI component can create widespread impact. A compromised upload script silently exfiltrated environment variables and secrets from customer pipelines.

Organizations continued operating normally while their CI environments leaked credentials.

CircleCI

The CircleCI Security Incident highlighted another reality of modern pipelines:

CI/CD platforms frequently become centralized repositories for highly privileged credentials.

Compromise the platform, and you compromise the secrets.

The Typical CI/CD Attack Chain

Most CI/CD compromises follow a similar progression.

Step 1: Initial Access

Attackers gain a foothold through:

• Stolen developer credentials
• OAuth token abuse
• Vulnerable plugins
• Misconfigured repositories
• Supply chain dependencies
• Exposed runners

Initially, privileges are often limited.

Step 2: Pipeline Discovery

Next, attackers map the trust relationships:

• Workflow definitions
• Deployment jobs
• Secret references
• Service accounts
• Cloud integrations
• Artifact repositories

The goal is understanding how software moves from source code to production.

Step 3: Secret Extraction

Many workflows expose credentials directly:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Attackers modify workflow behavior to capture these values during execution. Even temporary credentials can provide a path to larger compromises.

Step 4: Privilege Escalation

Harvested credentials enable movement into:

• Cloud environments
• Kubernetes clusters
• Internal services
• Artifact registries
• Deployment systems

At this point, the pipeline becomes a launch platform for broader attacks.

Step 5: Supply Chain Manipulation

This is where the impact becomes significant.

Attackers may:

• Insert backdoors
• Add malicious dependencies
• Modify container images
• Inject credential stealers
• Alter software updates

Customers receive compromised software through trusted delivery channels.

The Pipeline Is Becoming an Identity Provider

Historically, CI/CD systems authenticated to cloud providers using long-lived secrets. This model is rapidly changing.

Modern platforms increasingly use OpenID Connect (OIDC) federation to obtain temporary credentials directly from cloud providers.

For example, GitHub Actions can authenticate to AWS without storing AWS credentials inside GitHub Secrets.

Instead of:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Organizations increasingly use:

permissions:
  id-token: write

The workflow requests a short-lived identity token and exchanges it for temporary AWS credentials.

This is a major security improvement. However, it also introduces a new reality:

If an attacker can manipulate workflow execution, they may not need to steal credentials at all. They can simply obtain legitimate credentials directly from the cloud provider.

The attack surface shifts from secret theft to identity abuse.

This is why workflow integrity has become just as important as credential protection.

The Hidden Risks of GitHub Actions

GitHub Actions has become one of the most common CI/CD targets.

Consider:

on:
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

The workflow appears harmless. However, risks emerge when:

• Untrusted pull requests trigger execution
• Third-party actions are not pinned
• Secrets become available during execution
• Self-hosted runners process attacker-controlled code

An attacker may not need repository write access. They simply need their code to execute inside the trusted environment.

Self-Hosted Runners: The Forgotten Attack Surface

Many organizations deploy self-hosted runners with:

• Internal network access
• Persistent storage
• Long-lived credentials
• Broad cloud permissions

Unlike ephemeral cloud-hosted runners, self-hosted systems often retain artifacts, caches, logs, and temporary files between jobs.

This persistence creates opportunities for:

• Credential harvesting
• SSH key theft
• Token extraction
• Container escape attempts
• Lateral movement

A build runner should be viewed as an internet-facing workload executing untrusted code. Because that is exactly what it is.

Artifact Integrity Matters More Than Ever

Protecting the pipeline itself is no longer sufficient. Organizations must also verify the integrity of build outputs.

Questions worth asking include:

• Can we prove where an artifact originated?
• Can we prove which source code produced it?
• Can we prove which pipeline generated it?
• Can we detect unauthorized modifications?

This is where modern initiatives such as SLSA (Supply-chain Levels for Software Artifacts), Sigstore, Cosign, and build provenance become important.

The goal is not merely building software securely. The goal is proving that software was built securely.

Without provenance and artifact verification, organizations are forced to trust the pipeline blindly. History has shown that this trust can be dangerous.

CI/CD Is a Distributed System

Many teams think of CI/CD as a single platform.

In reality, it is a distributed system composed of:

• Source control systems
• Build runners
• Artifact repositories
• Secrets managers
• Cloud providers
• Deployment orchestrators

Each component introduces assumptions about trust.

Security failures frequently occur not within individual components but at the boundaries between them.

A runner trusts the repository.

The cloud trusts the runner.

Production trusts the artifact.

Attackers often target these trust transitions rather than the systems themselves.

Understanding these relationships is a core responsibility of modern security architecture.

Defending the Pipeline

Organizations should secure CI/CD with the same rigor applied to production systems.

1. Enforce Least Privilege

Avoid broad permissions whenever possible.

2. Use Ephemeral Credentials

Prefer OIDC federation and short-lived tokens over static secrets.

3. Isolate Build Environments

Use ephemeral runners, immutable infrastructure, and network segmentation.

4. Pin Dependencies

Pin actions and dependencies to immutable versions or commit hashes.

5. Protect Workflow Files

Treat pipeline definitions as security-sensitive code.

6. Monitor Pipeline Activity

Track:

• Workflow changes
• Secret access events
• Runner registrations
• Privilege escalations
• External network connections

7. Implement Artifact Signing and Provenance

Ensure deployments can be traced back to verified source code and verified build systems.

Threat Modeling CI/CD

When evaluating CI/CD security, ask:

• Can untrusted code reach the build environment?
• Which secrets are exposed during execution?
• Can workflows obtain cloud identities?
• Can artifacts be modified after creation?
• Who can approve pipeline changes?
• Are artifacts signed and verifiable?
• Can runners access internal systems?

These questions often reveal risks that traditional application threat models overlook.

Conclusion

Many organizations assume production is their most important attack surface.

Increasingly, that assumption is wrong.

Modern CI/CD systems possess extraordinary privileges, deep trust relationships, and direct paths into nearly every critical environment. They are no longer just automation platforms.

They are identity providers, deployment authorities, software factories, and trust engines. Attackers understand this.

That is why software supply chain attacks continue to grow.

If production is the castle, CI/CD is the drawbridge.

And compromising the drawbridge is often far easier than attacking the walls.

The most dangerous vulnerability in your environment may not be running in production at all.

It may be running every time your pipeline starts.