Your CI/CD pipeline is the most privileged system in your infrastructure. It has access to source code, production credentials, deployment keys, and the ability to push code to production. If an attacker compromises your pipeline, they compromise everything.
Supply chain attacks targeting CI/CD have exploded in recent years â and most organizations are woefully unprepared.
The Attack Surface
Real-World Supply Chain Attacks
18,000
Orgs Hit by SolarWinds
4 mo
Codecov Secret Exfiltration
8M+
ua-parser Malicious Downloads
600K
3CX Users Backdoored
Attack Pattern 1: Dependency Poisoning
Publish a malicious package
Typosquatting (colors.js vs c0lors.js), dependency confusion (internal package name on public registry), or account takeover of a popular maintainer
Victim installs it
Automated CI/CD pipeline runs npm install / pip install without integrity checks
Malicious code runs in CI
The package's postinstall script or imported code executes during build with full pipeline permissions
Secrets exfiltrated
Pipeline secrets, environment variables, and source code sent to attacker's server
Attack Pattern 2: CI/CD Configuration Injection
Submit a pull request
Attacker forks a public repo and modifies the CI configuration (.github/workflows, .gitlab-ci.yml)
CI runs on the PR
If the CI/CD system runs workflows from the PR branch (not the base branch), the attacker's modified workflow executes
Access secrets
The modified workflow dumps secrets, installs a backdoor, or pushes malicious artifacts
đGitHub Actions: pwn_request
The pull_request_target trigger in GitHub Actions runs with write permissions and access to secrets â even on PRs from forks. This has been exploited in attacks against major open-source projects.
Attack Pattern 3: Build System Compromise
The SolarWinds attack pattern â compromise the build system itself:
- Inject malicious code during the build process (not in source control)
- Modify artifacts after they're built but before they're signed
- Tamper with build tools or compilers to inject backdoors
The Defense Playbook
1. Dependency Security
Vulnerable Practices
- âĸNo lockfile pinning (uses latest)
- âĸNo integrity verification
- âĸAuto-merge Dependabot PRs
- âĸWide dependency trees with hundreds of transitive deps
Secure Practices
- âĸPin exact versions in lockfiles
- âĸVerify checksums (npm audit signatures, pip hash checking)
- âĸReview dependency updates manually for sensitive projects
- âĸMinimize dependencies and audit transitive deps
2. Pipeline Hardening
Pipeline Security Controls
Least privilege
Give CI/CD jobs only the permissions they need. Don't pass production credentials to test jobs. Use separate environments for build, test, and deploy.
Ephemeral environments
Use fresh, ephemeral build environments for every run. Never reuse build agents across jobs from different repositories or trust levels.
Secret management
Never put secrets in code or CI config files. Use dedicated secret managers (Vault, AWS Secrets Manager). Rotate secrets regularly. Audit access logs.
Signed commits and artifacts
Require signed commits on the main branch. Sign build artifacts and container images. Verify signatures before deployment.
3. Workflow Security
- Never run CI configs from PRs â Always use the base branch's workflow definitions
- Require approval for external PRs â Don't let anyone trigger your CI by opening a PR
- Restrict secret access â Only expose secrets to jobs that need them
- Immutable artifacts â Build once, deploy the same artifact to all environments
- Audit logs â Log and monitor all CI/CD activity for anomalies
4. Container Security
Base Images
Use minimal, official base images. Pin by digest, not tag.
Scan
Scan images for CVEs before pushing to registry (Trivy, Grype)
Sign
Sign images with cosign/Sigstore for provenance verification
Enforce
Only allow signed, scanned images to deploy to production
The Maturity Model
âšī¸Where Are You?
Level 1: No dependency pinning, secrets in environment variables, no artifact signing. Level 2: Lockfiles pinned, secrets in a manager, CI configs reviewed. Level 3: Signed commits, signed artifacts, ephemeral builds, dependency review, SBOM generation. Level 4: Full SLSA Level 3 compliance, hermetic builds, provenance attestation.
Most organizations are at Level 1 or 2. Getting to Level 3 eliminates the vast majority of supply chain attack vectors.
Worried about your CI/CD security? Request a security review â we assess your entire pipeline, from dependency management to deployment, and provide a prioritized remediation plan.