Top 10 CI/CD Security Risks

CI/CD pipelines hold the keys to production, yet they are often the least governed systems in the estate. A pipeline can read source code, pull dependencies, hold cloud and registry credentials, sign releases and deploy, so whoever controls a single job can often reach everything downstream. This page follows the OWASP Top 10 CI/CD Security Risks (CICD-SEC-1 to CICD-SEC-10), keeping OWASP's numbering and names as the authoritative list, and adds evidence from incidents in the NHI Mgmt Group breach database plus the controls that would have stopped them. It is written for platform, DevSecOps and AppSec teams. For a broader treatment, see the CI/CD Security Guide.

The Top 10 at a glance

The OWASP project groups CI/CD risk into ten categories. Several of them are identity problems in disguise: who can push, which credentials a job holds and whether a third-party service is trusted with secrets. The table pairs each risk with an incident it helps explain.

1. Insufficient Flow Control Mechanisms

The risk: an attacker who gains rights anywhere in source control, CI or an artefact repository can push code or artefacts all the way to production because no second person or process has to approve.

Evidence: in the GhostAction campaign, compromised GitHub accounts committed new workflows directly, and those workflows ran and exfiltrated 3,325 secrets.

What to do: branch protection with required review on every branch that feeds a sensitive pipeline, minimal bypass lists, tight auto-merge rules with no third-party code in scope, extra approval before production deployments, and promotion only of artefacts produced by an approved CI service account. Detect drift between production and its CI/CD source.

2. Inadequate Identity and Access Management

The risk: CI/CD estates accumulate human and machine identities across source control, CI, registries and clouds: personal access tokens, stale contributor accounts, shared service accounts and overly broad organisation owners.

Evidence: a fake CircleCI login page let attackers into the Dropbox GitHub organisation and 130 repositories.

What to do: SSO with phishing-resistant MFA for every CI/CD system, a single inventory of human and machine identities per system, removal of unused accounts and tokens, and no personal tokens in automation. See the CI/CD Pipeline Identity Security Guide.

3. Dependency Chain Abuse

The risk: builds and workstations fetch a malicious package through dependency confusion, a hijacked maintainer account, typosquatting or brandjacking, and its install script runs with whatever the job can reach.

Evidence: the PyTorch torchtriton attack used dependency confusion to steal SSH keys from nightly users; the Shai-Hulud worm spread through stolen publishing tokens.

What to do: route downloads through an internal proxy, pin vetted versions with lockfiles, verify checksums and signatures, use organisation scopes for private packages, commit package manager configuration such as .npmrc, and run install scripts in a context without secrets.

4. Poisoned Pipeline Execution (PPE)

The risk: someone who can change code, but not the build system, makes the pipeline run their commands. OWASP names three forms: Direct PPE (editing the CI configuration), Indirect PPE (editing files the configuration calls, such as Makefiles, scripts or test code) and Public PPE, or 3PE (pull requests to public repositories).

Evidence: in the Ultralytics compromise, an injection in a GitHub Actions workflow led to malicious releases of a popular AI library.

What to do: run unreviewed code on isolated runners with no secrets, require approval for workflows from forks and first-time contributors, avoid checking out pull request code in pull_request_target or workflow_run jobs, pass untrusted values such as pull request titles through environment variables rather than inline scripts, and protect CI configuration files with code owners. See the GitHub and GitHub Actions Security Guide.

5. Insufficient PBAC (Pipeline-Based Access Controls)

The risk: execution nodes and steps can reach far more secrets, hosts and networks than their task needs, so one poisoned step moves laterally.

Evidence: Travis CI CVE-2021-41077 let builds from forked pull requests read public projects' secrets.

What to do: separate runners by sensitivity, scope secrets to the job and environment that needs them, reset or discard nodes after every run, run jobs as a low-privilege OS user, segment runner networks and restrict outbound internet access. Never use self-hosted runners for public repositories.

6. Insufficient Credential Hygiene

The risk: long-lived secrets in code, CI variables, container layers, logs and build artefacts, often far broader than needed and rarely rotated.

Evidence: ArtiPACKED showed public Actions artefacts leaking live tokens; Ultralytics was worsened by a leftover PyPI token.

What to do: OIDC federation to clouds and registries instead of stored keys, PyPI-style trusted publishing (minted tokens last 15 minutes), read-only default GITHUB_TOKEN permissions, secret masking and scanning of logs and artefacts, and rotation on any suspicion. See the Top 10 Secrets Management Mistakes.

7. Insecure System Configuration

The risk: CI servers, source control, registries and runners run unpatched versions, default settings, broad network exposure or excessive admin rights.

Evidence: Russia's SVR exploited TeamCity CVE-2023-42793 on internet-facing build servers.

What to do: treat CI/CD systems as tier-0: patch on a critical SLA, remove them from direct internet exposure where possible, harden configuration as code, and review admin rights and plugin inventories quarterly.

8. Ungoverned Usage of 3rd Party Services

The risk: SaaS CI, GitHub Apps, OAuth apps and third-party actions are connected with broad access to code and secrets, and nobody tracks or reviews them.

Evidence: the CircleCI breach exposed every customer's stored secrets; the tj-actions/changed-files compromise, reached via reviewdog, leaked secrets from thousands of repositories that referenced a mutable tag.

What to do: approval and inventory for every integration, least-privilege scopes, an allowlist of actions pinned to full commit SHAs, and a rotation plan for each provider's credentials in case it is breached.

9. Improper Artifact Integrity Validation

The risk: code, scripts and artefacts move through the pipeline without anyone checking they are what they claim to be.

Evidence: in the Codecov breach, a modified Bash Uploader script harvested secrets from customers' CI environments; the HashiCorp GPG key was one casualty.

What to do: sign artefacts at creation and verify before every consuming step, verify hashes of downloaded scripts, generate signed provenance (SLSA Build L2 or higher) and enforce it at deploy. Sigstore keyless signing ties signatures to the workflow identity. See the SLSA and Build Provenance Guide.

10. Insufficient Logging and Visibility

The risk: CI/CD audit logs are not collected, retained or watched, so malicious workflow changes and secret use go unnoticed.

Evidence: the Megalodon attack used 5,718 malicious commits to turn 5,561 repositories into CI secret stealers, the kind of workflow change an alert on modified workflow files is built to catch.

What to do: stream source control, CI, registry and cloud audit logs to the SIEM; alert on new or modified workflow files, branch protection changes, new tokens and deploy keys, and outbound connections from runners to unknown hosts.

Mapping to OWASP and ATT&CK

OWASP numbering is the reference. ATT&CK techniques (v20) describe how attackers exploit each gap; NIST SP 800-53 Rev. 5 controls are the closest control anchors. This mapping is NHI Mgmt Group's own.

Where to start

1. Inventory credentials first: list every token, key and integration that CI/CD holds, revoke the unused, and move cloud and registry access to OIDC (risks 2, 6, 8).
2. Close the PPE paths: audit workflows for pull_request_target, inline use of untrusted input and secrets exposed to fork builds (risk 4).
3. Pin and allowlist third-party actions to commit SHAs (risks 3, 8).
4. Enforce review on release branches and remove bypasses (risk 1).
5. Turn on logging and alerts for workflow and permission changes (risk 10).
6. Add signing and provenance, then enforce verification in audit mode before blocking (risk 9).

Track progress with: number of long-lived CI credentials; percentage of third-party actions pinned by SHA; percentage of release branches with enforced review; mean time to revoke a leaked pipeline secret; and percentage of releases with verified provenance. If a pipeline is already compromised, use the CI/CD Pipeline Compromise Playbook.

Standards and references

• OWASP: Top 10 CI/CD Security Risks
• OWASP: CICD-SEC-4 Poisoned Pipeline Execution
• GitHub Docs: Security hardening for GitHub Actions
• OpenSSF: SLSA Specification v1.2
• PyPI: Trusted Publishers
• Sigstore: Overview
• MITRE ATT&CK: Compromise Software Supply Chain
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: CI/CD Security Guide · Software Supply Chain Security Guide · Top 10 Supply Chain Attacks · Secrets Management Guide