TL;DR

• Credentials are the multiplier: OWASP's Top 10 CI/CD Security Risks cover ten distinct trust failures, but exposed or overprivileged credentials (CICD-SEC-6) make nearly every other risk more dangerous once attackers gain a foothold.
• Attacks are accelerating: Since 2025, worms like Shai-Hulud, Miasma, and ChainDrop have compromised hundreds of packages, and GitGuardian's 2026 report found 59% of machines hit in one early wave were CI/CD runners.
• Fix starts at the source: GitGuardian's credential layer security spans developer endpoints, source control, and pipelines using ggshield, container scanning, and Developer Endpoint Protection to cut off attacker access before it spreads.

CI/CD pipelines have become a high-value target

Continuous integration and continuous delivery/deployment (CI/CD) systems have a lot of privileged access inside the enterprise. They connect the code developers write to the infrastructure where that code eventually runs. Along the way towards production, they touch source repositories, build systems, package registries, cloud platforms, deployment tools, and secrets. They also carry a lot of risk.

Attackers have noticed and have ramped up attacks since 2025. Many of these malicious campaigns take the form of infostealer attacks via self-propagating worms, such as Shai-Hulud, Miasma, and, more recently, ChainDrop, which compromised hundreds of packages across multiple ecosystems, including some packages with millions of weekly downloads. The 2026 GitGuardian State of Secrets Sprawl Report showed that 59% of the machines compromised in one early wave of these attacks were CI/CD runners.

OWASP built its Top 10 CI/CD Security Risks around defending this critical part of the modern software supply chain. 

The project examines how attackers can exploit the systems and trust relationships that move software from a developer workstation to production. It covers 10 different risk areas, but one keeps showing up underneath many of the others: credentials. 

A malicious package is much more useful if it can steal a token. A poisoned pipeline is much more dangerous if the job can reach production credentials. Weak access controls become a bigger problem when the identity behind them carries broad standing privilege.

Let's first take a look at the whole list before we examine how lax credential security magnifies the risk. 

The OWASP Top 10 CI/CD Security Risks

1.CICD-SEC-1: Insufficient flow control mechanisms

CI/CD pipelines need controls that prevent a single person or compromised account from pushing code or artifacts all the way to production. Without required reviews, approvals, and protected branches, an attacker who gains access to one part of the pipeline may be able to ship malicious changes without anyone finding out until too late.

2.CICD-SEC-2: Inadequate identity and access management

CI/CD environments contain a huge number of human and machine identities spread across source control, build systems, registries, and deployment tools. Overprivileged, stale, shared, or poorly managed identities give attackers more ways into the software delivery process and more authority once an identity is compromised.

3.CICD-SEC-3: Dependency chain abuse

Attackers can manipulate how build systems and developer machines retrieve dependencies, causing malicious packages to be downloaded and executed instead of trusted ones. Techniques such as dependency confusion, package hijacking, typosquatting, and brandjacking can turn a normal dependency installation into an entry point for credential theft, lateral movement, or malicious code.

4.CICD-SEC-4: Poisoned pipeline execution (PPE)

An attacker with access to source control may be able to change pipeline configuration files, scripts, tests, or other files that the build process executes. When the pipeline runs those changes, the attacker effectively gains the build job's role and permissions, potentially exposing credentials, infrastructure, and production deployment capabilities.

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

Build pipelines often need powerful access to source code, credentials, registries, infrastructure, and deployment environments to do their jobs. If that access is not tightly scoped to individual pipelines and stages, malicious code running inside a build can use those permissions to steal data, move laterally, or deploy malicious artifacts.

6.CICD-SEC-6: Insufficient credential hygiene

CI/CD systems depend heavily on secrets and tokens, which can end up exposed in source code, build logs, container layers, environment variables, or poorly protected pipeline configurations. Long-lived, overly permissive, and poorly managed credentials give attackers usable access that can extend from development systems all the way into production.

7.CICD-SEC-7: Insecure system configuration

Every SCM, CI server, artifact repository, runner, and deployment platform brings its own security settings, network controls, permissions, and patching requirements. Weak defaults, outdated software, excessive privileges, or exposed services can give attackers an easy foothold and a path toward credentials, build processes, and production systems.

8.CICD-SEC-8: Ungoverned usage of 3rd party services

CI/CD environments frequently connect third-party apps, plugins, actions, and external services directly to engineering systems. Without visibility and governance over what these services can access, every integration can expand the organization's attack surface and inherit powerful permissions into code, pipelines, and credentials.

9.CICD-SEC-9: Improper artifact integrity validation

Organizations need a reliable way to prove that code and artifacts moving through the pipeline have not been modified or replaced along the way. Without signing, verification, hashes, or other integrity controls, a malicious artifact can potentially move through trusted delivery processes and arrive in production looking legitimate.

10.CICD-SEC-10: Insufficient logging and visibility

Security teams need visibility into both human and programmatic activity across source control, CI systems, registries, and deployment infrastructure. Missing or disconnected logs can allow attackers to operate undetected and leave defenders without enough evidence to understand what happened, what was accessed, or how far the compromise spread. 

The common thread: attackers abusing trusted access

Step back from the individual risks and a larger pattern starts to emerge. This list is anchored on preventing attackers from abusing trust. 

CI/CD systems exist to take trusted instructions and turn them into real actions, often with very little human involvement. They merge code, run builds, pull dependencies, create artifacts, access infrastructure, and deploy into production. That makes the pipeline incredibly powerful, and it means an attacker does not necessarily need to break into production directly. They just need a way into something the pipeline already trusts.

That access can take many forms. A compromised developer account can push malicious code. A poisoned dependency can execute on a build runner. An overprivileged pipeline, misconfigured service, ungoverned third-party integration, or unverified artifact can then give that initial foothold somewhere to move laterally. Insufficient logging compounds the problem by allowing that abuse to continue without defenders clearly seeing what the attacker is doing.

CI/CD security is fundamentally about controlling who and what can exercise authority inside the software delivery process. 

The risks describe different paths in, different trust failures, and different ways an attacker can move through the system, but the danger is attackers stealing legitimate access to code, systems, infrastructure, or deployment paths. 

If defenders want to reduce the impact of many of these risks at once, they need to look closely at what grants that authority, how far it reaches, and how easily an attacker can turn it against them.

Why credential hygiene is the lynchpin of CI/CD Security

Right in the middle of the list is CICD-SEC-6, Insufficient Credential Hygiene. This makes sense as credentials are what turn access into authority. 

CI/CD environments are full of secrets, tokens, deploy keys, service account credentials, cloud keys, registry credentials, and API tokens that allow one system to talk to another and keep the delivery process moving. OWASP calls out how widely these credentials are spread across repositories, pipelines, build processes, artifacts, logs, and production deployment workflows. Once an attacker gets hold of one, they are no longer just standing inside the pipeline. They may have a legitimate way to act as something the organization already trusts.

That makes poor credential hygiene a force multiplier for many of the other risks on the list, and OWASP explicitly connects several of these risks to overly permissive identities, pipeline permissions, and credentials that can be accessed from the wrong context. Weak IAM becomes far more dangerous when an overprivileged identity has a long-lived token attached to it. Insecure system configuration can expose default credentials or permissive tokens, while third-party services can become pathways to the secrets they have been granted. Even weak flow controls become more damaging when the attacker already possesses the credentials needed to move code or artifacts farther down the delivery chain. 

Credentials deserve special attention here, as they are often what let an attacker turn an initial foothold into persistence, lateral movement, data access, or deployment authority, making finding, controlling, and eliminating exposed standing credentials one of the highest-leverage places to start.

GitGuardian's credential layer security reduces risk across the CI/CD attack surface

Getting credential hygiene right has an outsized impact because it takes away one of the main things attackers need to turn a CI/CD foothold into a larger compromise: usable authority. If the path an attacker takes does not lead to an exposed, long-lived, or overly powerful credential, it becomes much harder for malware, a human attacker, or a rogue AI agent to move from that initial compromise into another system. Addressing CICD-SEC-6 therefore helps reduce the blast radius of several other risks on the OWASP list at the same time.

That is the idea behind credential layer security. 

GitGuardian is a credential-layer security platform built to protect credentials across developers, repositories, pipelines, build systems, cloud services, and production infrastructure. Those credentials rarely stay neatly within one tool, and protecting them requires visibility into both where credentials should exist and where they have leaked, been copied, or are being used.

Detecting secrets is the first step, then add context

The GitGuardian platform's native source integrations can continuously monitor GitHub, GitLab, Bitbucket, and Azure DevOps, including historical code, while container scanning extends detection into images where credentials can survive the build process.

Inside the pipeline itself, ggshield, the GitGuardian CLI, gives teams a way to make credential detection part of CI/CD execution. ggshield can scan commits and changes as builds run in GitHub Actions, GitLab pipelines, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines, and other common CI systems. Teams can make that scan an actual control point in the delivery process. In GitHub Actions, for example, the GitGuardian scan can be configured as a required status check so a pull request containing a detected secret cannot move forward until the problem is addressed.

GitGuardian can also connect to the systems where non-human identities and their credentials are created, stored, and consumed. Through NHI Governance, integrations with secrets managers, including HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, and others, help show every team where credentials are stored and whether they are where they are supposed to be. This connection to vaults works both ways, empowering GitGuardian's Push-to-Vault functionality 

CI and infrastructure integrations with GitHub Actions, GitLab CI, and Kubernetes help show where those identities are actually being used. Cloud IAM integrations with AWS IAM and Microsoft Entra ID can then add context about the permissions associated with discovered credentials and the potential blast radius if one is exposed.

Knowing that a string in a repository looks like an AWS key is useful. Knowing that the credential is valid, is being consumed by a production pipeline, maps back to a particular non-human identity, carries powerful permissions, and is or is not properly represented in a secrets manager gives defenders a much clearer picture of what needs attention first. GitGuardian's NHI integrations are designed to inventory these identities and add context around their usage, scope, lifecycle, and security posture rather than leaving every secret finding as an isolated alert.

An ounce of credential prevention is worth a pound of leakage cure

The same detection and protections can start before CI/CD ever gets involved. Developers can use ggshield through pre-commit, pre-push, and pre-receive hooks, as well as integrations with development environments such as VS Code, Cursor, and Windsurf. GitGuardian has also extended these guardrails into AI-assisted development, where ggshield hooks can inspect activity from tools such as Cursor, Claude Code, and GitHub Copilot before credentials get passed into an AI workflow or pushed farther down the software delivery chain. 

Developer Endpoint Protection extends that coverage even farther left, onto the machines feeding code into or running the CI/CD tooling in the first place. Developer laptops and on-prem machines can accumulate credentials in .env files, shell histories, cloud profiles, CLI caches, IDE configurations, MCP configurations, and AI agent histories that may never appear in a repository. GitGuardian can deploy endpoint scanning through existing MDM tools such as Intune, Jamf, and Kandji, identify those credentials locally, and feed the resulting findings into the same security workflows. Honeytokens can also be planted on developer machines to provide a tripwire when an infostealer or other attacker starts harvesting credentials from an endpoint.

Put these pieces together and the larger GitGuardian platform strategy starts to come into focus. Detect exposed credentials across the places developers, pipelines, and machines actually work. Add context from CI/CD, infrastructure, secrets managers, and IAM to understand the identities and authority behind them. Remediate the credentials that create real risk, then prevent new exposures closer to where they originate. 

GitGuardian's platform brings those motions together around the credential layer instead of asking security teams to manage every repository, pipeline, developer endpoint, vault, and identity system as a completely separate problem.

Turn credential hygiene into CI/CD resilience

The OWASP Top 10 shows how many different ways attackers can get into trusted software delivery paths and abuse the access already there. Credential hygiene helps limit what happens next. A poisoned dependency, compromised developer, or malicious build step is far less dangerous when it cannot reach a valid credential that opens another door.

That gives teams a very practical place to make progress. By finding exposed credentials across developer endpoints, repositories, pipelines, images, and connected cloud and identity systems, then removing, constraining, or preventing that access, organizations can reduce the blast radius of many CI/CD attacks at once.

The goal is not to slow CI/CD down. It is to keep all that automation and connectivity working while making the credential layer stronger, safer, and much harder for attackers to abuse.