OWASP Top 10 CI/CD Security Risks: Pipeline Controls

The OWASP Top 10 CI/CD Security Risks is a stable 2022 list of risks in the systems and processes that build, test, and release software. Its categories cover change flow, identity and access, dependencies, poisoned pipeline execution, pipeline-based access, credentials, configuration, third-party services, artifact integrity, and visibility.

The official OWASP Top 10 CI/CD Security Risks remains the project’s stable v1.0 release. The list addresses the delivery environment around application code, including source control, automation services, runners, build dependencies, artifact repositories, deployment systems, and cloud identities.

A pipeline often has more production authority than an individual developer. It can read source and secrets, mint cloud credentials, produce trusted artifacts, change infrastructure, and deploy across environments. Compromise in this path can turn an approved code change into a release that no reviewer actually saw.

Key Takeaways

• Protect the path from proposed change to production with independent review, protected branches, controlled workflows, and environment approvals.
• Use individual human identities and task-specific workload identities instead of shared accounts or static deployment credentials.
• Build from pinned dependencies in isolated runners, then sign and verify immutable artifacts before deployment.
• Log source changes, workflow definitions, approvals, identity issuance, runner activity, artifacts, and deployments under connected identifiers.

What the CI/CD Top 10 Covers

CI/CD security is broader than placing a scanner in a workflow. The pipeline itself is a privileged application with users, configuration, dependencies, credentials, external integrations, data flows, and production side effects. It needs an architecture and access model of its own.

The list uses pipeline-based access controls to describe authorization decisions that depend on how and where automation runs. A developer may have permission to propose code while a protected workflow holds permission to deploy it. If the same developer can modify that workflow or choose an unrestricted runner, the apparent separation disappears.

Several entries overlap with software supply chain and cloud security. That overlap is useful because build identities, dependencies, artifact provenance, and deployment policy meet inside CI/CD. The list helps teams examine how those controls connect.

OWASP CI/CD Security Top 10 Risks Explained

CICD-SEC-1: Insufficient flow control mechanisms

Flow controls determine how code and configuration move from a contributor into a protected branch and production. Missing review, bypassable branch rules, self-approval, weak ownership, and direct deployment paths can let one compromised identity ship a change.

Require independent review for sensitive code and workflow files, protect branches and tags, and limit emergency bypass. Separate proposal, approval, and deployment authority where impact warrants it. Test rules with administrators, automation users, forks, bots, and alternate release paths.

CICD-SEC-2: Inadequate identity and access management

CI/CD platforms contain human accounts, service users, bots, runners, applications, deploy keys, and cloud principals. Shared accounts, broad roles, dormant users, weak federation, and long sessions make activity hard to attribute and expand compromise.

Use individual accounts with strong authentication and short administrative sessions. Give workloads separate identities tied to repository, workflow, branch, environment, and task. Review access after role changes and remove inactive users, tokens, applications, and runners.

CICD-SEC-3: Dependency chain abuse

Pipelines download packages, actions, plugins, images, compilers, scripts, and tools before they handle trusted source. Name confusion, compromised maintainers, mutable versions, and unsafe installation hooks can execute attacker code inside a credentialed build environment.

Pin exact revisions and digests, use controlled repositories, review new dependencies, and separate dependency resolution from privileged release steps. Disable unnecessary installation scripts and network access. Verify provenance and scan both direct and transitive components.

CICD-SEC-4: Poisoned pipeline execution

Poisoned pipeline execution occurs when attacker-controlled content changes pipeline behavior. A pull request may modify a workflow directly, alter a script the workflow calls, change a configuration file, or inject data that later becomes a command.

Do not run untrusted change content with production secrets or write tokens. Review every file that influences execution, including build scripts, task definitions, makefiles, package hooks, and referenced configuration. Use isolated runners and fixed workflow logic for forked or external contributions.

CICD-SEC-5: Insufficient pipeline-based access controls

Pipeline-based access control fails when any workflow, branch, repository, or runner can reach sensitive credentials and environments. A low-trust test pipeline may receive the same cloud role as a protected deployment workflow.

Bind credentials and environment access to exact workflow identity and context. Require protected environments and approvals for production, restrict which repositories and branches may request a role, and deny unknown runners. A job name or repository membership is not enough to prove deployment authority.

CICD-SEC-6: Insufficient credential hygiene

Secrets appear in repository history, variables, logs, artifacts, images, caches, command lines, and developer copies. Static cloud keys and shared deployment tokens remain valuable long after one pipeline run ends.

Use workload identity federation to issue short-lived credentials at runtime. Store remaining secrets in managed systems, mask values, restrict retrieval, rotate automatically, and scan source and artifacts. The workload identity federation guide explains issuer, subject, audience, and trust policy in cloud token exchanges.

CICD-SEC-7: Insecure system configuration

CI/CD platforms, runners, agents, repositories, caches, webhooks, and artifact stores all carry security settings. Public runners, weak network boundaries, exposed administration, default accounts, unsafe container privilege, and permissive webhooks create paths outside application review.

Define secure configuration baselines in code and compare live state with them. Patch supported components, isolate runners, restrict management networks, validate webhook signatures, and remove unused services. Review hosted platform organization settings as well as repository configuration.

CICD-SEC-8: Ungoverned usage of third-party services

External applications can gain access to source, pull requests, issues, artifacts, user identity, and deployment events through OAuth grants, marketplace apps, webhooks, and API tokens. A convenient integration may retain access after its original owner leaves.

Maintain an integration catalog with publisher, owner, permissions, data, callback endpoints, installation scope, review date, and offboarding condition. Approve narrow organization or repository access and monitor use. Remove abandoned applications and rotate credentials after vendor compromise.

CICD-SEC-9: Improper artifact integrity validation

If deployment fetches an artifact by a mutable tag or unauthenticated location, the released bytes may differ from what the pipeline tested. A compromised registry, storage system, or promotion step can replace the package after approval.

Create immutable artifacts once, calculate digests, sign provenance, and promote the same object across environments. Deployment should verify the expected identity, signature, digest, source revision, and build process before use. Protect signing and verification policy from the artifact store itself.

CICD-SEC-10: Insufficient logging and visibility

Default logs may show a job succeeded without recording who changed the workflow, which identity received a token, what runner executed it, or which artifact reached production. Attackers may also delete short-lived runners and logs after use.

Collect source-control audit, platform administration, workflow, runner, identity provider, secret access, artifact, cloud, and deployment events. Use stable identifiers to connect a commit and approval with the resulting artifact and release. Protect retention and alert on policy bypass, unusual token issuance, runner registration, and workflow changes.

Secure Pipeline Design Separates Trust Levels

External contributions, ordinary branch builds, release candidates, and production deployment do not have the same trust. Running all of them on one persistent runner with shared credentials collapses those boundaries. Separate workflows, identities, networks, caches, and workspaces according to the authority they need.

Untrusted jobs should receive no production credentials and little write access. They can compile or test inside disposable environments, then publish results through a controlled channel. A trusted release job should consume reviewed source and pinned inputs rather than reuse a workspace that an untrusted job modified.

Production deployment needs a clear subject. Record the approved source revision, workflow revision, artifact digest, runner identity, approving person, deployment identity, target environment, and outcome. This chain supports both prevention and incident response.

How to Test CI/CD Security

Begin with an influence map. List every file, setting, event, integration, dependency, and identity that can change pipeline execution or release output. Include repository administrators, bot accounts, reusable workflows, package hooks, remote scripts, runner images, and environment rules.

Test changes from the lowest-trust contributor. Attempt to modify a workflow indirectly, print or exfiltrate secrets, write to protected branches, poison caches, alter artifacts, register a runner, and request production cloud access. Confirm that controls deny the action rather than relying on reviewers to notice a clever change.

Exercise revocation and recovery. Disable an identity during a job, remove a runner, rotate a signing key, compromise an artifact repository, and roll back a release. Verify that active authority stops, trusted artifacts remain distinguishable, and audit records support a complete timeline.

CI/CD, OSS, and Application Top 10 Lists Are Complementary

The CI/CD list focuses on delivery systems and workflow. The OWASP open source list covers component selection, maintenance, provenance, mutability, and licensing. The OWASP Top 10 2025 guide covers application risks in the released software.

One dependency attack can touch all three areas. A malicious package enters through OSS selection, executes in a weak pipeline, and introduces an application backdoor. Use shared inventory and provenance data while retaining separate controls at selection, build, and runtime.

Frequently Asked Questions

What is the latest OWASP CI/CD Security Top 10 version?

The OWASP project page identifies v1.0 from October 2022 as its stable release. The categories remain useful, but teams should pair them with current platform and cloud guidance. Reports should name the project and version rather than implying a yearly update.

What is poisoned pipeline execution?

Poisoned pipeline execution occurs when an attacker changes a file, parameter, dependency, or configuration that influences automation. The visible workflow may remain unchanged while a referenced script executes hostile code. Protection requires influence mapping, isolation, restricted credentials, and review of every execution input.

Should CI jobs use static cloud credentials?

Static credentials increase exposure time and are often copied across variables, runners, and repositories. Workload identity federation can issue short-lived access after verifying repository and workflow claims. The cloud trust policy still needs narrow subjects, audiences, permissions, and environments.

Does adding security scanning secure a pipeline?

Scanning may find vulnerable code, dependencies, secrets, or configuration, but it does not protect the pipeline control plane. Attackers can target identities, workflow rules, runners, credentials, integrations, and artifact promotion. Pipeline security needs controls around how the scanner and every other job execute.