CI/CD Attacks

By /

⚙️ CI/CD as Attack Surface: Compromising the Build Pipeline

By James K. Bishop, vCISO | Founder, Stage Four Security

Continuous Integration and Continuous Deployment (CI/CD) pipelines power the modern development lifecycle. But they also present a powerful—and often overlooked—attack surface. When attackers compromise your build process, they can inject malicious code, exfiltrate secrets, or corrupt every artifact your app produces.This post unpacks the anatomy of CI/CD pipeline attacks and lays out defensive practices to keep your software supply chain secure from commit to deploy.

🔓 Why CI/CD Is a High-Value Target

  • Privileged access: CI/CD systems can read secrets, access source code, push to production, and alter infrastructure
  • Trusted output: Users implicitly trust binaries and containers produced by build systems
  • Automation = amplification: A compromised pipeline distributes malware at scale

If an attacker owns your pipeline, they own everything you ship.

🎯 Real-World CI/CD Attacks

  • SolarWinds (SUNBURST): Nation-state actors injected a trojan into the Orion platform via the build process
  • CodeCov Bash Uploader breach: Exposed credentials via a tampered installer script
  • Dependency confusion (Alex Birsan): Attackers injected malicious packages into internal pipelines by mimicking private dependencies

These aren’t theoretical risks—they’re happening now.

🚨 Common Pipeline Weaknesses

  • 🔑 Long-lived secrets: Hardcoded API keys, tokens, or credentials in environment variables
  • 📥 Unvalidated dependencies: Pulling packages or tools from unauthenticated or unsigned sources
  • 🏗️ Privileged runners: CI agents running as root or with broad cloud IAM roles
  • 📤 Overpermissive artifact access: Public or unauthenticated access to build outputs
  • ⛓️ Monolithic workflows: Every job runs with full access to code, secrets, and infra—no segmentation

🛡️ Securing the CI/CD Pipeline

  • Use ephemeral runners: Destroy build agents after each job to limit persistence
  • Enforce least privilege: Assign narrowly scoped permissions for each build task
  • Scan dependencies and tools: Validate everything downloaded or executed during builds
  • Use secure artifact storage: Apply encryption and access control to build outputs
  • Rotate and vault secrets: Use secret managers (e.g., HashiCorp Vault, AWS Secrets Manager)

⚙️ Recommended Tools

  • 🔍 Supply chain attestation: Sigstore, cosign, in-toto for artifact signing and traceability
  • 🔒 CI/CD security scanners: Checkov, tfsec, KICS for IaC and pipeline code review
  • 📦 Dependency verification: Use lockfiles, hash checks, and pinned versions
  • 🔗 Secure build orchestration: GitHub Actions, GitLab CI, CircleCI, Jenkins with hardened runners

📣 Final Thought

The integrity of your build pipeline is the integrity of your product. Attackers have realized this—and they’re aiming earlier and deeper into your development process. The good news? You can defend it, but only if you treat the CI/CD system not just as automation—but as infrastructure that must be secured like any other critical system.

Need help hardening your CI/CD pipelines, evaluating exposure, or building a secure-by-design release process? Let’s talk.

Scroll to Top