The OWASP CI/CD Top 10: A Practical Breakdown (With Real Examples)

In 2021, attackers compromised SolarWinds' build pipeline — not the product itself — and slipped malicious code into a signed, trusted update that reached roughly 18,000 organizations, including US government agencies. No application vulnerability was exploited. The pipeline was the target.

Your CI/CD pipeline holds credentials to your cloud, your registries, your Kubernetes clusters, and your source code — often with far less scrutiny than the application itself ever gets. That's exactly the gap OWASP's CI/CD Security Top 10 was built to close: a list of the most common ways attackers compromise software delivery pipelines instead of the software they deliver.

Below is a walkthrough of all 10 risks, with an example and a mitigation for each.

CICD-SEC-1: Insufficient Flow Control Mechanisms

The risk: The pipeline doesn't enforce that code actually passes through the required stages — tests, code review, security scans — before it ships.

Example: A developer pushes directly to a branch that triggers a production deploy job, bypassing the pull request review and the SAST scan stage entirely, because the pipeline trusts branch names rather than enforcing gates.

Mitigation:

• Enforce branch protection rules and required status checks before merge (tests, SAST, SCA).
• Make pipeline stages non-skippable — no manual "continue anyway" buttons on security gates.
• Use policy-as-code (e.g., OPA/Gatekeeper, or native branch protection APIs) so gate enforcement isn't dependent on a human remembering to click the right button.

CICD-SEC-2: Inadequate Identity and Access Management

The risk: Pipeline identities (service accounts, API tokens, bot users) have more permissions than they need, and there's no separation between "who can trigger a build" and "who can approve a production deploy."

Example: A Jenkins service account used to deploy to a Minikube cluster also has admin rights on the production Argo CD instance, because it was easier to reuse one token than provision two.

Mitigation:

• Apply least privilege per environment — separate credentials/service accounts for dev, staging, and prod.
• Use short-lived, scoped tokens (OIDC federation instead of static long-lived secrets where possible).
• Regularly audit who and what can trigger deployments, not just who can read code.

CICD-SEC-3: Dependency Chain Abuse

The risk: Attackers compromise the software supply chain feeding your build — malicious packages, typosquatted libraries, or compromised base images — rather than attacking your code directly.

Example: Your build pulls a transitive dependency that was recently taken over by a new maintainer who published a version containing a credential-stealing payload triggered at build time.

Mitigation:

• Pin dependency versions and use lockfiles; avoid floating "latest" tags for both packages and base images.
• Use a private package registry/proxy (e.g., Nexus, Artifactory) with vulnerability scanning before packages reach your build.
• Verify package signatures/provenance (e.g., Sigstore, npm provenance) where supported.

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

The risk: An attacker manipulates pipeline configuration files (Jenkinsfile, .gitlab-ci.yml, GitHub Actions workflows) to run malicious commands with the pipeline's privileges.

Example: A malicious pull request from an external contributor modifies the Jenkinsfile to add a stage that exfiltrates the SonarQube token or Docker Hub credentials — and it runs automatically because the pipeline builds PRs without human approval.

Mitigation:

• Never auto-run pipelines on PRs from forks/external contributors without a manual approval gate.
• Treat pipeline definition files with the same review rigor as application code (CODEOWNERS on Jenkinsfile/*.yml).
• Run untrusted PR builds in an isolated, credential-less environment.

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

The risk: Access controls exist at the source-code repo level, but not at the pipeline level — meaning anyone who can edit a pipeline config can effectively grant themselves broader access than their repo permissions imply.

Example: A developer with only "read" access to a repo can still modify the CI configuration for a shared pipeline job (like a reusable Jenkins shared library) that runs with elevated deploy permissions.

Mitigation:

• Restrict who can modify pipeline definitions and shared libraries independently from repo-level permissions.
• Use separate approval workflows for changes to pipeline infrastructure versus application code.
• Log and alert on pipeline configuration changes specifically.

CICD-SEC-6: Insufficient Credential Hygiene

The risk: Secrets are hardcoded, overly long-lived, shared across environments, or stored in plaintext within pipeline configs or environment variables.

Example: Your Docker Hub credentials for your app image are stored as a plaintext environment variable in a Jenkins job instead of Jenkins Credentials Store, and the same token is reused across three different pipelines.

Mitigation:

• Use a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, Jenkins Credentials Binding) — never hardcode secrets in Jenkinsfiles or YAML.
• Rotate credentials regularly and scope one credential per pipeline/environment, not shared globally.
• Scan repos and pipeline logs for accidentally leaked secrets (e.g., gitleaks, trufflehog).

CICD-SEC-7: Insecure System Configuration

The risk: The CI/CD platform itself is misconfigured — exposed dashboards, default credentials, permissive network access, or outdated software.

Example: Your Jenkins instance is reachable on the network without MFA enabled, still uses a default admin account, or has the script console exposed — giving anyone who reaches it arbitrary code execution on the build server.

Mitigation:

• Harden the CI/CD platform itself: disable default accounts, enforce MFA/SSO, restrict network exposure (no public Jenkins dashboards).
• Keep the CI/CD tooling (Jenkins, Argo CD, GitLab, etc.) patched and monitor for CVEs specific to your version.
• Apply the same configuration baseline/CIS benchmark discipline to CI/CD infra as you would to production servers.

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

The risk: Pipelines integrate with external SaaS tools (notification services, testing platforms, marketplace plugins/actions) without vetting what access those integrations actually have.

Example: A Jenkins plugin installed for convenience has permissions to read all pipeline environment variables, including deploy credentials, and the plugin's marketplace listing hasn't been security-reviewed in years.

Mitigation:

• Maintain an approved allowlist of third-party plugins/actions/integrations; review permissions before installation.
• Regularly audit installed plugins and remove unused ones — every plugin is additional attack surface.
• Prefer integrations that use scoped tokens over ones that request broad API access.

CICD-SEC-9: Improper Artifact Integrity Validation

The risk: There's no verification that the artifact deployed to production is actually the one that was built and tested — opening the door to tampering between build and deploy.

Example: Your GitOps flow pulls Image:latest from Docker Hub without checking a digest or signature, so if the tag gets overwritten (accidentally or maliciously) between CI build and Argo CD sync, a different image silently reaches the cluster.

Mitigation:

• Use immutable image tags or digests (image@sha256:...) instead of mutable tags like latest in your Argo CD manifests.
• Sign artifacts and verify signatures before deployment (Cosign/Sigstore, Notary).
• Generate and verify SBOMs so you know exactly what's in what you're shipping.

CICD-SEC-10: Insufficient Logging and Visibility

The risk: Pipeline activity isn't logged in enough detail to detect or investigate an incident — who triggered a build, what changed, what credentials were used.

Example: An unauthorized deploy happens through your Minikube/Argo CD setup, but there's no centralized log correlating the Jenkins build trigger, the Docker Hub push, and the Argo CD sync — so reconstructing what happened takes days instead of minutes.

Mitigation:

• Centralize logs from every stage of the pipeline (SCM, CI, registry, CD) into one place — feed them into your Prometheus/Grafana or a SIEM.
• Log pipeline-specific events: who triggered builds, config changes, credential usage, deploy approvals.
• Set alerts for anomalies — off-hours deploys, unexpected pipeline modifications, failed auth attempts.

The pipeline holds the keys to everything like: source code, secrets, registries, and production clusters. Applying the same rigor here that we apply to application security (least privilege, integrity verification, logging, hardened configuration) closes one of the most overlooked gaps in the SDLC.

If you're building out CI/CD infrastructure — Jenkins, Argo CD, Kubernetes-based pipelines, or anything GitOps — treating these 10 risks as a checklist during design, not an afterthought during an incident, pays off enormously.

Reference: OWASP Top 10 CI/CD Security Risks

#DevSecOps #CyberSecurity #ApplicationSecurity #CloudSecurity #CICD #OWASP #Kubernetes #Docker #Jenkins #GitHubActions #GitLabCI #Security #InfoSec #DevOps