For most of the past decade, the security conversation around software delivery focused on the product — the web application, the API, the cloud environment where it runs. The pipeline that builds and deploys the product was treated as infrastructure, not as an attack surface. That assumption has proven dangerously wrong. CI/CD systems now hold more privileged access than almost any other component in a modern technology stack: production deployment credentials, code signing keys, cloud administrator access, package registry tokens, and direct write access to the codebase itself. Compromising a build system is no longer just about disrupting deployments — it is a direct path to poisoning every artifact you ship.
TL;DR: CI/CD pipelines are prime targets because they hold privileged access to production, signing keys, and cloud credentials. Common vulnerabilities include secrets in environment variables, unprotected PR pipelines with production access, and dependency confusion. Defenses include OIDC-based short-lived credentials, environment-scoped secrets, artifact signing, and regular pipeline security reviews.
Why CI/CD Systems Are Targeted
The privileged access held by CI/CD systems is the primary motivation. In a typical environment, a CI/CD pipeline needs to: deploy to production (AWS/GCP/Azure admin credentials), push container images (registry write access), publish packages (npm, PyPI, or internal registry tokens), sign releases (code signing certificates or GPG keys), and access secrets during testing (database credentials, API keys). This constellation of access makes the pipeline more dangerous than a compromised developer workstation — and often harder to monitor.
The secondary motivation is scale. The SolarWinds and Codecov supply chain attacks demonstrated that a single compromised build system can affect thousands of downstream customers. An attacker who injects malicious code into a widely-used CI/CD Action or build script gets distribution through every organization that uses it, without needing to breach each target individually.
Common CI/CD Vulnerabilities
Secrets stored as long-lived environment variables
The most common finding in CI/CD security reviews is static, long-lived credentials stored as repository secrets that never rotate. A single compromised developer account with access to repository settings, a malicious pull request that exfiltrates secrets via build logs, or a compromised third-party Action is enough to extract these credentials. Every secret that can be replaced with OIDC-based temporary credentials should be.
Pull request pipelines with production access
Pull request workflows need to run tests against code from external contributors, but they should never have access to production secrets. When a repository's CI/CD configuration applies the same secret scope to pull request triggers as to merge-to-main triggers, any contributor who can open a pull request can craft a workflow modification that exfiltrates production credentials. This is an extremely common misconfiguration in open-source and enterprise repositories alike.
Unpinned third-party Actions and dependencies
The tj-actions/changed-files compromise in March 2025 demonstrated the risk of referencing third-party Actions by mutable tag rather than immutable SHA. When you reference uses: tj-actions/changed-files@v35, you are trusting that the tag always points to the same commit. If the Action maintainer's account is compromised and a malicious commit is pushed to v35, every pipeline using that tag immediately runs attacker-controlled code with access to your secrets. Pinning to SHA (e.g., uses: tj-actions/changed-files@a59f800) prevents this entirely.
SSRF from build steps accessing internal services
Build runners often execute inside networks with access to internal services, metadata APIs, or cloud instance metadata endpoints. A build step that fetches a URL from a user-controlled input — such as a webhook URL, documentation link, or test fixture — may be able to reach internal infrastructure that is otherwise inaccessible from the internet. This makes CI/CD pipelines a vector for internal SSRF even when the build system itself is properly secured at the perimeter.
Notable Incidents
| Incident | Attack Vector | Impact | Key Lesson |
|---|---|---|---|
| Codecov (2021) | Compromised Docker image builder modified the Bash uploader script | Credentials exfiltrated from hundreds of companies including Twilio, Confluent, HashiCorp | Build scripts fetched from the internet during CI runs should be integrity-verified |
| CircleCI (2023) | Malware on an employee laptop harvested a 2FA-backed SSO session | Customer secrets stored in CircleCI were exposed; companies advised to rotate all secrets | Secrets stored in hosted CI platforms are only as secure as the platform itself |
| tj-actions (2025) | Compromised PAT token allowed malicious commit to popular GitHub Action | 23,000+ repositories ran malicious code that echoed secrets to public build logs | Third-party Actions must be pinned to SHA, not mutable tags |
| SolarWinds (2020) | Build environment compromised; malicious code injected into signed release | 18,000+ customers received backdoored software updates; major government breach | Build environment integrity is a security requirement, not just an ops one |
What Pentesters Look For in CI/CD Assessments
A thorough CI/CD security assessment examines several dimensions that are invisible to traditional web application penetration testing:
- Pipeline-as-code review. Every workflow file (GitHub Actions YAML, Jenkinsfile, GitLab CI YAML) is reviewed for secret handling, trigger configuration, third-party Action pinning, and privilege scope. This is essentially a code review for your deployment infrastructure.
- Secret scope audit. Which secrets are accessible to which workflow triggers? Can a pull request pipeline access production secrets? Are secrets scoped to the minimum necessary environment?
- Branch protection verification. Are merge requirements enforced? Can a developer bypass required reviews by targeting a branch that triggers deployment? Is the production branch protected against direct pushes?
- Artifact integrity. Are build artifacts signed before deployment? Is there a process to verify that the artifact being deployed was produced by the intended build process from the expected source commit?
- Third-party dependency review. Are all external Actions and build dependencies pinned to verified, immutable references? Is there a process for monitoring security advisories for build dependencies separate from application dependencies?
Defensive Measures
Switch to OIDC-based credential federation
Replace static long-lived cloud credentials with OIDC federation. GitHub Actions, GitLab CI, and CircleCI all support native OIDC token exchange with AWS, GCP, and Azure. Your pipeline authenticates by exchanging a short-lived, job-scoped JWT for temporary cloud credentials that expire within minutes. This eliminates the risk class of static credential theft from CI/CD environments.
Isolate environments by secret scope
Production credentials should only be accessible to workflows that run on protected branches after a merge — never to pull request workflows. Use environment-level secret scoping in GitHub Actions (environments with protection rules), separate pipeline configurations for PR vs. merge, or branch filters on sensitive job definitions.
Pin all third-party dependencies to SHA
Replace every @vX reference with @SHA. This is a one-time investment that prevents entire classes of supply chain compromise. Tools like dependabot and renovate can be configured to submit automated PRs when the underlying commit for a pinned reference changes, making maintenance practical.
Implement artifact signing with Sigstore
Sigstore's Cosign provides free, keyless artifact signing that records provenance in a public transparency log. Signed artifacts allow deployment systems to verify that a container image or binary was produced by your CI/CD system from a specific source commit — catching any tampering that occurs after the build completes.
How secure is your build pipeline?
Lorikeet Security's DevSecOps security assessments review your CI/CD pipeline configuration, secret management, and supply chain controls for the vulnerabilities that enable build system compromise.
