OWASP Top 10 CI/CD Risks Explained with Real-World Examples

CI/CD pipelines have become the backbone of modern software delivery. But with that power comes significant risk. The OWASP Top 10 CI/CD Security Risks project catalogues the most critical attack vectors targeting continuous integration and continuous delivery systems. In this guide, we break down each risk with real-world examples, impact assessments, and actionable mitigations you can apply to GitHub Actions, GitLab CI, and other platforms today.

Overview Table: OWASP Top 10 CI/CD Risks at a Glance

ID	Risk Name	Core Problem	Severity
CICD-SEC-1	Insufficient Flow Control Mechanisms	No enforcement of approval gates before code reaches production	Critical
CICD-SEC-2	Inadequate Identity and Access Management	Overly permissive identities across pipeline systems	Critical
CICD-SEC-3	Dependency Chain Abuse	Malicious packages injected through the software supply chain	High
CICD-SEC-4	Poisoned Pipeline Execution (PPE)	Attackers manipulate pipeline definitions to execute malicious code	Critical
CICD-SEC-5	Insufficient PBAC (Pipeline-Based Access Controls)	Pipelines granted excessive permissions beyond what jobs require	High
CICD-SEC-6	Insufficient Credential Hygiene	Secrets exposed in logs, repos, or overly shared across pipelines	Critical
CICD-SEC-7	Insecure System Configuration	Default or misconfigured CI/CD platform settings	High
CICD-SEC-8	Ungoverned Usage of 3rd Party Services	Unvetted third-party integrations with pipeline access	Medium
CICD-SEC-9	Improper Artifact Integrity Validation	No verification that build outputs haven’t been tampered with	High
CICD-SEC-10	Insufficient Logging and Visibility	Inability to detect or investigate pipeline-based attacks	Medium

Let’s dive into each risk in detail.

CICD-SEC-1: Insufficient Flow Control Mechanisms

What Is It?

Flow control mechanisms are the gates and guardrails that govern how code moves from a developer’s workstation to production. When these controls are insufficient, an attacker — or even a rogue insider — can push code directly to a production branch without peer review, bypass required approvals, or skip critical security checks like SAST and SCA scans.

Real-World Example

In 2021, a researcher demonstrated how a single developer at a major tech company could bypass branch protection rules by pushing directly to the default branch when branch protections were not enforced for administrators. The result: untested, unreviewed code deployed straight to production, with no audit trail of approval. Similarly, many organizations configure their pipelines to auto-deploy on merge but forget to enforce minimum reviewer counts or status check requirements.

Impact

An attacker who bypasses flow controls can inject backdoors, disable security tooling, or alter deployment configurations — all without anyone noticing until it’s too late. This is the gateway risk: if your flow controls are weak, every subsequent control becomes less effective.

Mitigations

Enforce branch protection rules on all critical branches. Require at least two approving reviews before merge, and do not allow administrators to bypass these rules.
Require status checks to pass before merge, including SAST, linting, and unit tests.
Use CODEOWNERS files to mandate reviews from specific teams for sensitive paths (e.g., .github/workflows/, Dockerfile, Terraform files).
Enable signed commits and verify them in your pipeline. See our guide on Secure Pipeline Labs for a hands-on walkthrough.

CICD-SEC-2: Inadequate Identity and Access Management

What Is It?

CI/CD environments span multiple systems — source control, build servers, artifact registries, cloud providers, and deployment targets. Each system has its own identity model. Inadequate IAM means identities (human or machine) have excessive privileges, stale accounts persist, or there is no centralized governance over who or what can do what across the pipeline.

Real-World Example

The Codecov supply chain attack (April 2021) exploited an overly permissive service account. Attackers modified the Codecov Bash Uploader script to exfiltrate environment variables — including CI tokens and secrets — from thousands of customer CI/CD pipelines. Because those CI tokens had broad permissions (often write access to repos and package registries), attackers could move laterally across the entire delivery chain.

Impact

Excessive privileges mean a single compromised identity can read secrets, modify code, alter pipeline definitions, push malicious artifacts, and pivot to production cloud environments. The blast radius is enormous.

Mitigations

Apply the principle of least privilege to every identity — human users, bot accounts, and service tokens.
Use short-lived, scoped credentials instead of long-lived personal access tokens. GitHub’s OIDC integration with cloud providers is a strong pattern.
Audit and rotate credentials regularly. Revoke access for offboarded team members immediately.
Centralize identity management via SSO/SAML and enforce MFA for all CI/CD platform access. Learn more in our Identity & Access guides.

CICD-SEC-3: Dependency Chain Abuse

What Is It?

Modern applications pull hundreds or thousands of dependencies from public registries (npm, PyPI, Maven Central, Docker Hub). Dependency chain abuse occurs when an attacker injects malicious code into a package your pipeline automatically installs — through typosquatting, dependency confusion, or compromising an existing maintainer account.

Real-World Example

In the ua-parser-js incident (October 2021), a widely used npm package with over 7 million weekly downloads was compromised when an attacker gained access to the maintainer’s npm account. They published malicious versions that installed cryptominers and credential stealers. Any CI/CD pipeline running npm install without pinned versions pulled the trojanized package automatically.

Impact

Compromised dependencies execute within your build environment with full access to environment variables, secrets, and network connectivity. They can exfiltrate credentials, inject backdoors into your own build artifacts, or mine cryptocurrency on your infrastructure.

Mitigations

Pin dependencies to exact versions and use lockfiles (package-lock.json, Pipfile.lock, go.sum).
Enable dependency review in pull requests using tools like dependency-review-action for GitHub Actions.
Use a private registry or proxy (Artifactory, Nexus) to cache and scan packages before they enter your build.
Implement Software Composition Analysis (SCA) in every pipeline run. Check our Supply Chain Security guides for integration patterns.

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

What Is It?

Poisoned Pipeline Execution is one of the most dangerous CI/CD risks. It occurs when an attacker can modify the CI/CD pipeline configuration file (e.g., .github/workflows/, .gitlab-ci.yml, Jenkinsfile) and that modification is executed by the pipeline. There are three variants: Direct PPE (D-PPE), where the attacker modifies the pipeline file directly; Indirect PPE (I-PPE), where the attacker modifies files that the pipeline references (scripts, Makefiles); and Public PPE (3PE), where fork-based pull requests trigger pipelines in the target repository.

Real-World Example

In the GitHub Actions pull_request_target vulnerability wave (2020-2021), security researchers demonstrated that public repositories using the pull_request_target trigger with explicit checkout of PR code (via actions/checkout with ref: ${{ github.event.pull_request.head.sha }}) allowed any external contributor to execute arbitrary code within the context of the target repository — with access to its secrets. Major open-source projects including several Apache Foundation repos were found vulnerable.

Impact

PPE gives attackers code execution inside your pipeline with access to secrets, deployment credentials, and the ability to modify build outputs. It’s effectively remote code execution on your CI/CD infrastructure.

Mitigations

Never use pull_request_target with actions/checkout of the PR’s head ref. Use pull_request instead for untrusted code.
Require approval for fork-based PR workflows in GitHub Actions settings (Settings > Actions > Fork pull request workflows).
Keep pipeline definitions in protected branches and restrict who can modify them.
Separate build and deploy pipelines: the build pipeline (which runs untrusted code) should never have access to production deployment credentials. See our hands-on labs for pipeline separation patterns.

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

What Is It?

PBAC refers to the access controls applied to the pipeline execution environment itself. Insufficient PBAC means pipelines have access to resources, secrets, and systems that are not needed for their specific job. This is the pipeline equivalent of violating least privilege — a build job for a frontend service has access to database production credentials, for example.

Real-World Example

Consider an organization running 50 microservices in a monorepo, all sharing a single CI/CD configuration. Every pipeline job — regardless of which service it builds — has access to every secret in the repository: production database URLs, AWS root keys, signing certificates. When a junior developer’s test job fails and dumps environment variables to the log for debugging, all 50 services’ secrets are exposed.

Impact

When a single pipeline job is compromised (through PPE, dependency abuse, or a malicious insider), insufficient PBAC means the attacker gains access to far more than the specific service being built. The blast radius expands to every system the pipeline can touch.

Mitigations

Scope secrets to specific environments and jobs. In GitHub Actions, use environment-scoped secrets with required reviewers for production environments.
Use OIDC federation for cloud access instead of storing static cloud credentials. Scope OIDC claims to specific repositories, branches, and environments.
Restrict GITHUB_TOKEN permissions using the permissions key at the workflow and job level. Default to read-all and grant write only where needed.
Isolate pipeline runners by sensitivity level — don’t run production deployment jobs on the same runners as PR validation jobs. See our CI/CD Security guides for architecture patterns.

CICD-SEC-6: Insufficient Credential Hygiene

What Is It?

Credentials (API keys, tokens, passwords, certificates) are the lifeblood of CI/CD pipelines. Insufficient credential hygiene refers to secrets that are hardcoded in code, stored in plaintext, printed in logs, shared too broadly, never rotated, or persist long after they should have been revoked.

Real-World Example

The Samsung leak (March 2022) saw the Lapsus$ group extract nearly 200 GB of source code from Samsung’s repositories, which contained hardcoded credentials including private signing keys and API keys embedded directly in source code. In CI/CD contexts, researchers regularly find secrets printed in build logs through debug output, env commands, or error messages that include authentication headers.

Impact

Exposed credentials give attackers direct access to downstream systems — cloud accounts, artifact registries, databases, and deployment targets — without needing to exploit any further vulnerabilities. One leaked AWS key can compromise an entire cloud environment.

Mitigations

Never hardcode secrets. Use your platform’s native secrets manager (GitHub Encrypted Secrets, GitLab CI/CD Variables with masking, HashiCorp Vault).
Enable secret scanning on all repositories to detect accidentally committed credentials. GitHub’s push protection blocks commits containing known secret patterns.
Mask secrets in logs. Most CI platforms support automatic masking, but verify it works for your custom outputs.
Rotate credentials on a schedule and immediately upon suspected exposure. Use short-lived tokens (OIDC, STS) wherever possible.
Run tools like trufflehog or gitleaks in your pipeline to catch secrets before they reach the default branch. See our Secrets Management guides for implementation details.

CICD-SEC-7: Insecure System Configuration

What Is It?

CI/CD platforms (Jenkins, GitHub Actions, GitLab CI, CircleCI, ArgoCD) come with default configurations that prioritize ease of use over security. Insecure system configuration covers misconfigurations such as: outdated software versions with known CVEs, overly permissive network access, self-hosted runners without hardening, disabled audit logging, and exposed administration interfaces.

Real-World Example

Thousands of Jenkins instances are exposed to the internet with default configurations, many running outdated versions with known remote code execution vulnerabilities (e.g., CVE-2024-23897, an arbitrary file read in Jenkins’ CLI). Shodan searches regularly reveal Jenkins servers with unauthenticated access to build logs, pipeline definitions, and stored credentials. In 2022, researchers found over 30,000 exposed Jenkins instances, many belonging to Fortune 500 companies.

Impact

A misconfigured CI/CD platform can expose credentials, allow unauthorized pipeline execution, provide attackers with a foothold into your internal network, and give them the ability to tamper with every artifact your organization produces.

Mitigations

Harden self-hosted runners/agents. Use ephemeral containers that are destroyed after each job. Never install runners on long-lived VMs that accumulate state.
Keep CI/CD platforms updated and subscribe to security advisories for your specific platforms.
Restrict network access to CI/CD administration interfaces. Use VPN or zero-trust network access.
Disable unnecessary features — if your org doesn’t use Jenkins CLI, disable it. If you don’t need SSH access to runners, turn it off.
Apply CIS benchmarks for your CI/CD platforms where available. Refer to our Pipeline Hardening guides for platform-specific checklists.

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

What Is It?

Modern CI/CD pipelines integrate with dozens of third-party services: code quality tools, security scanners, notification systems, deployment platforms, and marketplace actions. Ungoverned usage means these integrations are adopted without security review, granted excessive OAuth scopes, and not monitored for changes in behavior or ownership.

Real-World Example

The tj-actions/changed-files compromise (March 2025) demonstrated this risk dramatically. A widely-used GitHub Action was compromised through a chain of events: attackers first compromised the reviewdog/action-setup action, used it to steal a PAT from the tj-actions maintainer, then injected malicious code into tj-actions/changed-files. The malicious code dumped CI/CD secrets to build logs. Because thousands of repositories used this action with default (unpinned) version references, the blast radius was enormous.

Impact

A compromised third-party integration can read your source code, steal secrets, modify build outputs, and deploy malicious code — all within the trusted context of your pipeline. Because these tools often have broad OAuth scopes, a single compromise can cascade across your entire organization.

Mitigations

Pin third-party actions to full commit SHAs, not tags or branch names. Tags can be moved to point to malicious commits.
Use GitHub’s actions/allowed-actions policy to restrict which actions can run in your organization.
Audit OAuth app permissions regularly. Revoke access for tools no longer in use.
Enable Dependabot or Renovate to track updates to your action dependencies and review changes carefully before merging. See our Supply Chain Security section for governance frameworks.

CICD-SEC-9: Improper Artifact Integrity Validation

What Is It?

Build artifacts — container images, binaries, packages — flow through multiple systems between the build stage and deployment. Improper artifact integrity validation means there is no mechanism to verify that the artifact deployed to production is exactly the artifact produced by the trusted build pipeline, with no tampering in between.

Real-World Example

The SolarWinds SUNBURST attack (December 2020) is the definitive example. Attackers compromised SolarWinds’ build system and injected a backdoor into the Orion software during the build process. Because there was no independent verification of build output integrity, the trojanized update was signed with SolarWinds’ legitimate certificate and distributed to approximately 18,000 organizations, including multiple U.S. government agencies.

Impact

Without artifact integrity validation, attackers can replace legitimate builds with malicious ones, inject backdoors during the build-to-deploy transit, or replay older (vulnerable) versions of artifacts. Consumers of your software have no way to verify they received what you intended to ship.

Mitigations

Sign all build artifacts using tools like Sigstore/Cosign for containers or GPG for traditional packages.
Generate and distribute SBOMs (Software Bills of Materials) with each release using SPDX or CycloneDX format.
Implement SLSA (Supply-chain Levels for Software Artifacts) provenance attestations. SLSA Level 2+ ensures that build provenance is generated by the build service itself, not the developer.
Verify artifact checksums at every stage of the delivery pipeline — after build, after push to registry, and before deployment.
Use admission controllers (e.g., Kyverno, OPA Gatekeeper) in Kubernetes to reject unsigned or unattested images. See our Artifact Security guides for implementation walkthroughs.

CICD-SEC-10: Insufficient Logging and Visibility

What Is It?

If you can’t see what’s happening in your pipelines, you can’t detect attacks, investigate incidents, or demonstrate compliance. Insufficient logging and visibility means CI/CD events — pipeline executions, configuration changes, secret access, user logins, permission modifications — are not captured, not centralized, not monitored, or not retained long enough to support incident response.

Real-World Example

Many organizations discover CI/CD compromises weeks or months after the fact — if they discover them at all. In the Codecov breach, affected companies had difficulty determining exposure because their CI/CD logs either didn’t capture which environment variables were present during affected builds, or those logs had already been rotated out. Without centralized logging, teams were left guessing which secrets needed rotation.

Impact

Without visibility, every other risk on this list becomes harder to detect and respond to. Attackers can operate undetected, dwell time increases, and incident response becomes guesswork rather than evidence-based investigation. Compliance frameworks (SOC 2, ISO 27001) also require demonstrable audit trails for software delivery.

Mitigations

Centralize CI/CD logs in a SIEM or log management platform (Splunk, Elastic, Datadog). Don’t rely solely on the CI platform’s native log retention.
Monitor for anomalous pipeline behavior: unusual execution times, new workflow files, unexpected secret access, builds triggered at odd hours, or pipelines running from unrecognized branches.
Enable audit logging on all CI/CD platforms and SCM systems. GitHub Enterprise’s audit log, GitLab’s audit events, and Jenkins’ audit trail plugin are starting points.
Set up alerts for high-risk events: changes to workflow files, new OAuth app installations, branch protection rule modifications, and failed deployment approvals.
Retain logs for at least 90 days (longer for regulated industries). Ensure logs are immutable and tamper-evident. See our Monitoring & Logging guides for architecture patterns.

Building a Comprehensive CI/CD Security Program

Addressing the OWASP Top 10 CI/CD risks isn’t a one-time project — it’s an ongoing program. Here’s a prioritized approach:

Start with visibility (CICD-SEC-10): You can’t fix what you can’t see. Centralize logging first so you have a baseline.
Lock down access (CICD-SEC-2, CICD-SEC-5, CICD-SEC-6): Implement least privilege for identities, scope pipeline permissions, and clean up credential hygiene. These three risks together cover the most common attack surfaces.
Harden the pipeline (CICD-SEC-1, CICD-SEC-4, CICD-SEC-7): Enforce flow controls, prevent poisoned pipeline execution, and harden your CI/CD platform configurations.
Secure the supply chain (CICD-SEC-3, CICD-SEC-8, CICD-SEC-9): Pin dependencies, govern third-party integrations, and implement artifact signing and verification.

Each layer builds on the previous one. Without visibility, you can’t validate your access controls are working. Without access controls, hardening is easily bypassed. And without a hardened pipeline, supply chain controls can be circumvented.

Conclusion

The OWASP Top 10 CI/CD Security Risks provide a comprehensive framework for understanding and addressing the threats facing modern software delivery pipelines. As attacks like SolarWinds, Codecov, and tj-actions have shown, CI/CD pipelines are high-value targets that attackers are actively exploiting.

The good news: every risk on this list has practical, implementable mitigations. By systematically working through these risks — starting with visibility and access controls, then hardening pipelines and securing the supply chain — you can dramatically reduce your organization’s exposure to CI/CD-based attacks.

Ready to put this into practice? Explore our hands-on labs to implement these mitigations in real GitHub Actions and GitLab CI environments, or browse our CI/CD Security guides for platform-specific implementation details.